4. Raccomandazioni: Suite di cifratura

TLS 1.2 offriva una notevole flessibilità nella selezione delle suite di cifratura. Sfortunatamente, la sicurezza di alcune di queste suite si è degradata nel tempo al punto che alcune sono note per essere insicure (questo è uno dei motivi per cui TLS 1.3 ha limitato questa flessibilità). Una configurazione errata del server porta a una sicurezza assente o ridotta. Questa sezione include raccomandazioni sulla selezione e negoziazione delle suite di cifratura.

4.1. Linee guida generali

Gli algoritmi crittografici si indeboliscono nel tempo man mano che la crittoanalisi migliora: algoritmi che un tempo erano considerati forti diventano deboli. Pertanto, le suite di cifratura che utilizzano algoritmi deboli devono essere gradualmente eliminate e sostituite con suite più sicure. Questo aiuta a garantire che le proprietà di sicurezza desiderate siano ancora valide. SSL/TLS esiste da oltre 20 anni e molte delle suite di cifratura che sono state raccomandate in varie versioni di SSL/TLS sono ora considerate deboli o almeno non forti quanto desiderato. Pertanto, questa sezione modernizza le raccomandazioni riguardanti la selezione delle suite di cifratura.

• Le implementazioni NON DEVONO negoziare suite di cifratura con NULL encryption.

  Motivazione: Le suite di cifratura NULL non cifrano il traffico e quindi non forniscono alcun servizio di riservatezza. Qualsiasi entità sulla rete con accesso alla connessione può vedere il testo in chiaro del contenuto scambiato da client e server. Tuttavia, questo documento non scoraggia il software dall'implementare suite di cifratura NULL, in quanto possono essere utili per test e debug.

• Le implementazioni NON DEVONO negoziare suite di cifratura RC4.

  Motivazione: Il cifrario a flusso RC4 presenta varie debolezze crittografiche, come documentato in [RFC7465]. Si noti che DTLS proibisce già specificamente l'uso di RC4.

• Le implementazioni NON DEVONO negoziare suite di cifratura che offrono meno di 112 bit di sicurezza, inclusa la cosiddetta crittografia "Export-Grade" (che fornisce 40 o 56 bit di sicurezza).

  Motivazione: In base a [RFC3766], sono necessari almeno 112 bit di sicurezza. La sicurezza a 40 bit e 56 bit (che si trova nei cosiddetti "cifrari di esportazione") è considerata insicura oggi.

• Le implementazioni NON DOVREBBERO negoziare suite di cifratura che utilizzano algoritmi che offrono meno di 128 bit di sicurezza.

  Motivazione: Le suite di cifratura che offrono 112 bit o più ma meno di 128 bit di sicurezza non sono considerate deboli al momento; tuttavia, si prevede che la loro vita utile sia abbastanza breve da giustificare il supporto di suite di cifratura più forti a questo punto. Si prevede che i cifrari a 128 bit rimarranno sicuri per almeno diversi anni e i cifrari a 256 bit fino alla prossima svolta tecnologica fondamentale. Si noti che, a causa dei cosiddetti attacchi "meet-in-the-middle" [Multiple-Encryption], alcune vecchie suite di cifratura (ad esempio, Triple DES (3DES) a 168 bit) hanno una lunghezza effettiva della chiave inferiore alla loro lunghezza nominale della chiave (112 bit nel caso di 3DES). Tali suite di cifratura dovrebbero essere valutate in base alla loro lunghezza effettiva della chiave.

• Le implementazioni NON DOVREBBERO negoziare suite di cifratura basate sul trasporto di chiavi RSA, alias "RSA statico".

  Motivazione: Queste suite di cifratura, che hanno valori assegnati che iniziano con la stringa "TLS_RSA_WITH_*", presentano diversi svantaggi, in primis il fatto che non supportano la forward secrecy.

• Le implementazioni NON DOVREBBERO negoziare suite di cifratura basate su accordo di chiave Diffie-Hellman (DH) a campo finito non effimero (statico). Allo stesso modo, le implementazioni NON DOVREBBERO negoziare accordo di chiave Elliptic Curve DH non effimero.

  Motivazione: Le prime suite di cifratura, che hanno valori assegnati prefissati da "TLS_DH_", hanno diversi inconvenienti, principalmente il fatto che non supportano la forward secrecy. Anche le seconde ("TLS_ECDH_") mancano di forward secrecy e sono soggette ad attacchi di curva non validi [Jager2015].

• Le implementazioni DEVONO supportare e preferire negoziare suite di cifratura che offrono forward secrecy. Tuttavia, le implementazioni TLS 1.2 NON DOVREBBERO negoziare suite di cifratura basate su accordo di chiave Diffie-Hellman a campo finito effimero (cioè, suite "TLS_DHE_*"). Questo è giustificato dalla nota fragilità della costruzione (vedi [RACCOON]) e dalla limitazione intorno alla negoziazione, incluso l'uso di [RFC7919], che ha visto un'adozione molto limitata.

  Motivazione: La forward secrecy (chiamata a volte "perfect forward secrecy") impedisce il recupero di informazioni che sono state cifrate con vecchie chiavi di sessione, limitando così la quantità di dati che possono essere decifrati retroattivamente quando un attacco ha successo. Vedi le Sezioni 7.3 e 7.4 per una discussione dettagliata.

4.2. Suite di cifratura per TLS 1.2

Date le considerazioni precedenti, l'implementazione e la distribuzione delle seguenti suite di cifratura è RACCOMANDATA:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Poiché questi sono algoritmi di Authenticated Encryption with Associated Data (AEAD) [RFC5116], queste suite di cifratura sono supportate solo in TLS 1.2 e non nelle versioni precedenti del protocollo.

Tipicamente, per preferire queste suite, l'ordine delle suite deve essere esplicitamente configurato nel software del server. Sarebbe ideale se le implementazioni del software server preferissero queste suite di default.

Alcuni dispositivi hanno supporto hardware per AES Counter Mode with CBC-MAC (AES-CCM) ma non per AES Galois/Counter Mode (AES-GCM), quindi non sono in grado di seguire le raccomandazioni precedenti riguardanti le suite di cifratura. Esistono persino dispositivi che non supportano affatto la crittografia a chiave pubblica, ma questi sono completamente fuori ambito.

Una suite di cifratura che opera in modalità Cipher Block Chaining (CBC) (ad esempio, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) NON DOVREBBE essere utilizzata a meno che non venga negoziata con successo anche l'estensione encrypt_then_mac [RFC7366]. Questo requisito si applica sia alle implementazioni client che a quelle server.

Quando si utilizzano firme ECDSA per l'autenticazione dei peer TLS, è RACCOMANDATO che le implementazioni utilizzino la curva NIST P-256. Inoltre, per evitare nonce prevedibili o ripetuti (che potrebbero rivelare la chiave di firma a lungo termine), è RACCOMANDATO che le implementazioni implementino "ECDSA deterministico" come specificato in [RFC6979] e in accordo con le raccomandazioni di [RFC8446].

Si noti che le implementazioni di "ECDSA deterministico" possono essere vulnerabili a certi attacchi side-channel e fault injection proprio a causa del loro determinismo. Mentre la maggior parte degli attacchi fault injection descritti in letteratura presuppone l'accesso fisico al dispositivo (e sono quindi più rilevanti nelle distribuzioni Internet of Things (IoT) con sicurezza fisica debole o inesistente), alcuni possono essere condotti da remoto [Poddebniak2017], ad esempio sotto forma di varianti Rowhammer [Kim2014]. Nelle distribuzioni in cui gli attacchi side-channel e fault injection sono una preoccupazione, possono essere utilizzate strategie di implementazione che combinano casualità e determinismo (ad esempio, come descritto in [CFRG-DET-SIGS]) per evitare il rischio di estrazione riuscita della chiave di firma.

4.2.1. Dettagli di implementazione

I client DOVREBBERO includere TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 come prima proposta a qualsiasi server. I server DEVONO preferire questa suite di cifratura rispetto a suite di cifratura più deboli ogni volta che viene proposta, anche se non è la prima proposta. I client sono ovviamente liberi di proporre suite di cifratura più forti, ad esempio utilizzando AES-256; quando lo fanno, il server DOVREBBE preferire la suite di cifratura più forte a meno che non vi siano ragioni impellenti (ad esempio, prestazioni gravemente degradate) per scegliere diversamente.

La versione precedente delle raccomandazioni TLS [RFC7525] permetteva implicitamente la vecchia suite di cifratura Mandatory-to-Implement della RFC 5246, TLS_RSA_WITH_AES_128_CBC_SHA. Al momento della stesura, questa suite di cifratura non offre ulteriore interoperabilità, tranne che con client molto vecchi. Come con altre suite di cifratura che non offrono forward secrecy, le implementazioni NON DOVREBBERO supportare questa suite di cifratura. Altri protocolli applicativi specificano altre suite di cifratura come Mandatory-to-Implement (MTI).

[RFC8422] consente a client e server di negoziare parametri ECDH (curve). Client e server DOVREBBERO includere la "Supported Elliptic Curves Extension" [RFC8422]. Client e server DOVREBBERO supportare le curve NIST P-256 (secp256r1) [RFC8422] e X25519 (x25519) [RFC7748]. Si noti che [RFC8422] depreca tutto tranne il formato punto non compresso. Pertanto, se il client invia un'estensione ec_point_formats, la ECPointFormatList DEVE contenere un singolo elemento, "uncompressed".

4.3. Suite di cifratura per TLS 1.3

Questo documento non specifica alcuna suite di cifratura per TLS 1.3. I lettori sono rimandati alla Sezione 9.1 di [RFC8446] per le raccomandazioni sulle suite di cifratura.

4.4. Limiti sull'uso della chiave

Tutti i cifrari hanno un limite superiore sulla quantità di traffico che può essere protetto in modo sicuro con una determinata chiave. Nel caso delle suite di cifratura AEAD, vengono mantenuti due limiti separati per ciascuna chiave:

1. Limite di riservatezza (Confidentiality Limit, CL), ovvero il numero di record che possono essere cifrati.

2. Limite di integrità (Integrity Limit, IL), ovvero il numero di record a cui è consentito fallire l'autenticazione.

Quest'ultimo si applica a DTLS (e anche a QUIC) ma non a TLS stesso, poiché le connessioni TLS vengono interrotte al primo fallimento di decifrazione.

Quando un mittente si avvicina al CL, l'implementazione DOVREBBE avviare un nuovo handshake (in TLS 1.3, questo può essere ottenuto inviando un messaggio KeyUpdate sulla sessione stabilita) per ruotare la chiave di sessione. Quando un ricevitore ha raggiunto l'IL, l'implementazione DOVREBBE chiudere la connessione. Sebbene queste raccomandazioni siano una buona pratica, gli implementatori devono essere consapevoli che non è sempre facile realizzarle nei protocolli costruiti sopra TLS/DTLS senza introdurre un coordinamento attraverso i confini dei livelli. Vedi la Sezione 6 di [RFC9001] per un esempio della cooperazione che è stata necessaria in QUIC tra i livelli crypto e transport per supportare gli aggiornamenti delle chiavi. Si noti che in generale, i protocolli applicativi potrebbero non essere in grado di emulare questo metodo data la loro interazione più vincolata con TLS/DTLS. A causa di queste complessità, queste raccomandazioni non sono obbligatorie.

Per tutte le suite di cifratura TLS 1.3, i lettori sono rimandati alla Sezione 5.5 di [RFC8446] per i valori di CL e IL. Per tutte le suite di cifratura DTLS 1.3, i lettori sono rimandati alla Sezione 4.5.3 di [RFC9147].

Per tutte le suite di cifratura AES-GCM raccomandate per TLS 1.2 e DTLS 1.2 in questo documento, CL può essere derivato inserendo i parametri corrispondenti nelle disuguaglianze nella Sezione 6.1 di [AEAD-LIMITS] che si applicano ai nonce casuali parzialmente impliciti, ovvero la costruzione del nonce utilizzata in TLS 1.2. Sebbene le cifre ottenute siano leggermente superiori a quelle di TLS 1.3, è RACCOMANDATO utilizzare lo stesso limite di 2^24.5 record per entrambe le versioni.

Per tutte le suite di cifratura AES-GCM raccomandate per DTLS 1.2, IL (ottenuto dalle stesse disuguaglianze sopra menzionate) è 2^28.

4.5. Lunghezza della chiave pubblica

Quando si utilizzano le suite di cifratura raccomandate in questo documento, vengono normalmente utilizzate due chiavi pubbliche nell'handshake TLS: una per l'accordo di chiave Diffie-Hellman e una per l'autenticazione del server. Quando viene utilizzato un certificato client, viene aggiunta una terza chiave pubblica.

Con lo scambio di chiavi basato su gruppi Diffie-Hellman modulari esponenziali (MODP) (suite di cifratura "DHE"), sono RICHIESTE lunghezze della chiave DH di almeno 2048 bit.

Motivazione: Per vari motivi, in pratica, le chiavi DH sono tipicamente generate in lunghezze che sono potenze di due (ad esempio, 2^10 = 1024 bit, 2^11 = 2048 bit, 2^12 = 4096 bit). Poiché una chiave DH di 1228 bit sarebbe approssimativamente equivalente solo a una chiave simmetrica di 80 bit [RFC3766], è meglio usare chiavi più lunghe di questa per la famiglia di suite di cifratura "DHE". Una chiave DH di 1926 bit sarebbe approssimativamente equivalente a una chiave simmetrica di 100 bit [RFC3766]. Una chiave DH di 2048 bit (equivalente a una chiave simmetrica di 112 bit) è il minimo consentito dall'ultima revisione di [NIST.SP.800-56A] al momento della stesura (vedi in particolare l'Appendice D di quel documento).

Come notato in [RFC3766], la correzione per l'emergere della macchina TWIRL (The Weizmann Institute Relation Locator) [TWIRL] implicherebbe che le chiavi DH a 1024 bit diano circa 61 bit di forza equivalente e che una chiave DH a 2048 bit darebbe circa 92 bit di forza equivalente. L'attacco Logjam [Logjam] dimostra ulteriormente che i parametri Diffie-Hellman a 1024 bit dovrebbero essere evitati.

Per quanto riguarda le chiavi ECDH, gli implementatori sono rimandati al registro IANA "TLS Supported Groups" (precedentemente noto come "EC Named Curve Registry") all'interno del registro "Transport Layer Security (TLS) Parameters" [IANA_TLS] e in particolare ai gruppi "recommended". Le curve inferiori a 224 bit NON DEVONO essere utilizzate. Questa raccomandazione è in linea con l'ultima revisione di [NIST.SP.800-56A].

Quando si utilizza RSA, i server DEVONO autenticarsi utilizzando certificati con un modulo di almeno 2048 bit per la chiave pubblica. Inoltre, l'uso dell'algoritmo hash SHA-256 è RACCOMANDATO e SHA-1 o MD5 NON DEVONO essere utilizzati [RFC9155] (per maggiori dettagli, vedi anche [CAB-Baseline], la cui versione attuale al momento della stesura è 1.8.4). I client DEVONO indicare ai server che richiedono SHA-256 utilizzando l'estensione "Signature Algorithms" definita in TLS 1.2. Per TLS 1.3, lo stesso requisito è già specificato da [RFC8446].

4.6. HMAC troncato

Le implementazioni NON DEVONO usare l'estensione Truncated HMAC, definita nella Sezione 7 di [RFC6066].

Motivazione: L'estensione non si applica alle suite di cifratura AEAD raccomandate sopra. Tuttavia, si applica alla maggior parte delle altre suite di cifratura TLS. Il suo utilizzo è stato dimostrato essere insicuro in [PatersonRS11].