9. Considerazioni sulla Sicurezza (Security Considerations)
Tutte le considerazioni sulla sicurezza che si applicano a TLS si applicano anche all'uso di TLS con QUIC. La lettura completa di [TLS13] e dei suoi appendici è il modo migliore per comprendere le proprietà di sicurezza di QUIC.
Questa sezione riassume alcuni degli aspetti di sicurezza più importanti specifici dell'integrazione TLS, ma ci sono molti dettagli relativi alla sicurezza nel resto del documento.
9.1. Collegabilità Sessioni (Session Linkability)
L'uso dei ticket di sessione TLS consente al server e potenzialmente ad altre entità di correlare le connessioni stabilite dallo stesso client. Vedere Sezione 4.5 per ulteriori dettagli.
9.2. Attacchi Replay con 0-RTT (Replay Attacks with 0-RTT)
Come descritto nella Sezione 8 di [TLS13], l'uso dei dati early (anticipati) TLS espone al rischio di attacchi replay. L'uso di 0-RTT in QUIC è allo stesso modo vulnerabile agli attacchi replay.
Gli endpoint DEVONO (MUST) implementare e utilizzare le protezioni replay descritte in [TLS13]. Tuttavia, si riconosce che queste protezioni sono imperfette. Pertanto, sono necessarie considerazioni aggiuntive riguardo al rischio di replay.
QUIC non è vulnerabile agli attacchi replay, eccetto tramite le informazioni del protocollo applicativo che potrebbe trasportare. La gestione dello stato del protocollo QUIC basata sui tipi di frame definiti in [QUIC-TRANSPORT] non è vulnerabile al replay. L'elaborazione dei frame QUIC è idempotente e non può portare a uno stato di connessione non valido se i frame vengono riprodotti, riordinati o persi. Le connessioni QUIC non generano impatti che persistono oltre la durata della connessione, eccetto quelli generati dal protocollo applicativo fornito da QUIC.
I ticket di sessione TLS e i token di validazione degli indirizzi vengono utilizzati per trasportare informazioni di configurazione QUIC tra le connessioni, in particolare per consentire ai server di ripristinare in modo efficiente lo stato utilizzato nella stabilimento della connessione e nella validazione degli indirizzi. Questi NON DEVONO (MUST NOT) essere utilizzati per comunicare semantica applicativa tra endpoint. I client DEVONO (MUST) trattarli come valori opachi. La possibilità di riutilizzare questi token significa che è necessaria una protezione più forte contro il replay.
Un server che accetta 0-RTT su una connessione sostiene costi più elevati rispetto all'accettare una connessione senza 0-RTT. Questo include costi di elaborazione e calcolo più elevati. I server devono considerare la probabilità di replay e tutti i costi associati quando accettano 0-RTT.
In definitiva, la responsabilità di gestire il rischio di attacchi replay con 0-RTT ricade sul protocollo applicativo. I protocolli applicativo che utilizzano QUIC DEVONO (MUST) descrivere come il protocollo utilizza 0-RTT e le misure adottate per proteggersi dagli attacchi replay. Un'analisi del rischio di replay deve considerare tutte le caratteristiche del protocollo QUIC che trasportano semantica applicativa.
Disabilitare completamente 0-RTT è la difesa più efficace contro gli attacchi replay.
Le estensioni QUIC DEVONO (MUST) descrivere come gli attacchi replay influenzano la loro operazione o proibire il loro uso con 0-RTT. I protocolli applicativo DEVONO (MUST) o proibire l'uso di estensioni che trasportano semantica applicativa in 0-RTT oppure fornire strategie di mitigazione del replay.
9.3. Mitigazione Attacchi Riflessione Pacchetti (Packet Reflection Attack Mitigation)
Un piccolo ClientHello che genera un grande blocco di messaggi di handshake dal server può essere utilizzato in un attacco di riflessione dei pacchetti per amplificare il traffico generato da un attaccante.
QUIC ha tre difese contro questo attacco. Primo, i pacchetti contenenti un ClientHello DEVONO (MUST) essere riempiti fino a una dimensione minima. Secondo, quando risponde a un indirizzo sorgente non validato, ai server è vietato inviare più di tre volte il numero di byte ricevuti (vedere Sezione 8.1 di [QUIC-TRANSPORT]). Infine, poiché gli acknowledgment dei pacchetti Handshake sono autenticati, un attaccante cieco non può falsificarli. Insieme, queste difese limitano il livello di amplificazione.
9.4. Analisi Protezione Header (Header Protection Analysis)
[NAN] analizza algoritmi di crittografia autenticata che forniscono privacy del nonce, chiamata trasformazione "Hide Nonce (HN)". La struttura generale della protezione dell'intestazione di questo documento è una di questi algoritmi (HN1). La protezione dell'intestazione viene applicata dopo l'AEAD di protezione del pacchetto, campionando una serie di byte ("campione") dall'output dell'AEAD e crittografando i campi dell'intestazione utilizzando una funzione pseudo-casuale (PRF) come segue:
protected_field = field XOR PRF(hp_key, sample)
Le varianti di protezione dell'intestazione di questo documento utilizzano una permutazione pseudo-casuale (PRP) al posto di una PRF generica. Tuttavia, poiché tutte le PRP sono anche PRF [IMC], queste varianti non deviano dalla struttura HN1.
Poiché "hp_key" è diversa dalla chiave di protezione del pacchetto, la protezione dell'intestazione raggiunge la sicurezza AE2 definita in [NAN] e quindi garantisce la privacy di "field", che è l'intestazione del pacchetto protetta. Le varianti future della protezione dell'intestazione basate su questa costruzione DEVONO (MUST) utilizzare una PRF per garantire garanzie di sicurezza equivalenti.
L'uso della stessa chiave e campione di ciphertext più volte rischia di compromettere la protezione dell'intestazione. Proteggere due diverse intestazioni con la stessa chiave e campione di ciphertext rivela l'XOR dei campi protetti. Supponendo che l'AEAD agisca come una PRF, se vengono campionati L bit, la probabilità che due campioni di ciphertext siano identici si avvicina a 2^(-L/2), ovvero il limite del compleanno. Per gli algoritmi descritti in questo documento, quella probabilità è 1 su 2^64.
Per impedire a un attaccante di modificare l'intestazione del pacchetto, l'intestazione viene autenticata transitivamente utilizzando la protezione del pacchetto. L'intera intestazione del pacchetto fa parte dei dati associati autenticati. I campi protetti falsificati o modificati possono essere rilevati solo dopo la rimozione della protezione del pacchetto.
9.5. Canali Laterali Temporizzazione Protezione Header (Header Protection Timing Side Channels)
Un attaccante può indovinare i valori di un numero di pacchetto o di una fase chiave e far confermare la propria ipotesi attraverso un canale laterale di temporizzazione. Allo stesso modo, le ipotesi sulla lunghezza del numero di pacchetto possono essere tentate e confermate. Se il destinatario di un pacchetto scarta i pacchetti con numeri di pacchetto duplicati senza tentare di rimuovere la protezione del pacchetto, potrebbe rivelare attraverso un canale laterale che il numero di pacchetto corrisponde a un pacchetto ricevuto. Affinché l'autenticazione sia libera da canali laterali, l'intero processo di rimozione della protezione dell'intestazione, ripristino del numero di pacchetto e rimozione della protezione del pacchetto DEVE (MUST) essere applicato insieme senza temporizzazione o altri canali laterali.
Per l'invio di pacchetti, la costruzione e la protezione del payload del pacchetto e del numero di pacchetto DEVONO (MUST) essere prive di canali laterali che rivelino il numero di pacchetto o la sua dimensione codificata.
Durante un aggiornamento delle chiavi, il tempo necessario per generare nuove chiavi potrebbe rivelare attraverso un canale laterale di temporizzazione che si è verificato un aggiornamento delle chiavi. In alternativa, laddove un attaccante inietti pacchetti, questo canale laterale potrebbe rivelare il valore della fase chiave del pacchetto iniettato. Dopo aver ricevuto un aggiornamento delle chiavi, un endpoint DOVREBBE (SHOULD) generare e salvare il prossimo set di chiavi di protezione del pacchetto di ricezione, come descritto nella Sezione 6.3. Generando nuove chiavi prima di ricevere un aggiornamento delle chiavi, la ricezione del pacchetto non crea un segnale di temporizzazione che rivela il valore della fase chiave.
Questo dipende dal non eseguire questa generazione di chiavi durante l'elaborazione del pacchetto e potrebbe richiedere che un endpoint mantenga tre set di chiavi di protezione del pacchetto per la ricezione: per la fase chiave precedente, per la fase chiave corrente e per la fase chiave successiva. In alternativa, un endpoint può scegliere di differire la generazione del prossimo set di chiavi di protezione del pacchetto di ricezione fino a quando non scarta le chiavi precedenti, risultando nella necessità di mantenere solo due set di chiavi di ricezione in qualsiasi momento.
9.6. Diversità Chiavi (Key Diversity)
Quando si utilizza TLS, viene utilizzato lo scheduler di chiavi centrale di TLS. A seguito dell'integrazione dei messaggi di handshake TLS nel calcolo dei segreti, inclusa l'estensione dei parametri di trasporto QUIC, è garantito che le chiavi handshake e 1-RTT siano diverse da qualsiasi chiave che potrebbe essere generata da un server che esegue TLS su TCP. Per evitare la possibilità di sincronizzazione delle chiavi cross-protocol, vengono fornite misure aggiuntive per migliorare la separazione delle chiavi.
Le chiavi e gli IV di protezione del pacchetto QUIC sono derivati utilizzando etichette diverse dalle chiavi equivalenti di TLS.
Per mantenere questa separazione, le nuove versioni di QUIC DOVREBBERO (SHOULD) definire nuove etichette per la derivazione delle chiavi e degli IV di protezione del pacchetto e delle chiavi di protezione dell'intestazione. Questa versione di QUIC utilizza la stringa "quic". Altre versioni possono utilizzare un'etichetta specifica per la versione al posto di quella stringa.
Il segreto iniziale utilizza una chiave specifica per la versione QUIC negoziata. Le nuove versioni QUIC DOVREBBERO (SHOULD) definire un nuovo valore salt utilizzato nel calcolo del segreto iniziale.
9.7. Casualità (Randomness)
QUIC si basa sulla capacità degli endpoint di generare numeri casuali sicuri, sia direttamente per valori del protocollo come gli ID di connessione, sia transitivamente tramite TLS. Vedere [RFC4086] per la guida sulla generazione di numeri casuali sicuri.