6. Aggiornamento Chiavi (Key Update)
Una volta che l'handshake è confermato (vedere Sezione 4.1.2), un endpoint PUÒ (MAY) avviare un aggiornamento delle chiavi.
Il bit Key Phase (fase chiave) indica quali chiavi di protezione del pacchetto vengono utilizzate per proteggere il pacchetto. Il bit Key Phase viene inizialmente impostato a 0 per il primo set di pacchetti 1-RTT e si alterna per indicare ogni successivo aggiornamento delle chiavi.
Il bit Key Phase consente al ricevitore di rilevare un cambiamento nel materiale delle chiavi senza bisogno di ricevere il pacchetto contenente il cambiamento. Un endpoint che rileva un cambiamento nel bit Key Phase aggiorna le chiavi e decifra il pacchetto contenente il valore modificato.
L'avvio di un aggiornamento delle chiavi fa sì che entrambi gli endpoint aggiornino le chiavi. Questo è diverso da TLS, dove gli endpoint possono aggiornare le chiavi indipendentemente.
Questo meccanismo sostituisce il meccanismo di aggiornamento delle chiavi di TLS, che si basa sull'invio di un messaggio KeyUpdate. I messaggi KeyUpdate vengono inviati utilizzando chiavi di crittografia 1-RTT. Gli endpoint NON DEVONO (MUST NOT) inviare un messaggio TLS KeyUpdate. Gli endpoint DEVONO (MUST) trattare la ricezione di un messaggio TLS KeyUpdate come un errore di connessione di tipo 0x010a, equivalente a un alert TLS fatale unexpected_message (vedere Sezione 4.8).
La Figura 9 mostra il processo di aggiornamento delle chiavi. Il set di chiavi inizialmente in uso (identificato con @M) viene sostituito con chiavi aggiornate (identificate con @N). Il valore del bit Key Phase è indicato tra parentesi quadre [].
Iniziatore Risponditore
@M [0] Pacchetto QUIC
... aggiorna a @N
@N [1] Pacchetto QUIC
-------->
aggiorna a @N ...
Pacchetto QUIC [1] @N
<--------
Pacchetto QUIC [1] @N
contenente ACK
<--------
... consenti aggiornamento chiavi
@N [1] Pacchetto QUIC
contenente ACK per pacchetti @N
-------->
consenti aggiornamento chiavi ...
Figura 9: Aggiornamento Chiavi
6.1. Avvio Aggiornamento Chiavi (Initiating a Key Update)
Un endpoint mantiene segreti di lettura e scrittura separati e indipendenti per la protezione dei pacchetti. Un endpoint avvia un aggiornamento delle chiavi aggiornando il suo segreto di scrittura della protezione dei pacchetti e utilizzandolo per proteggere nuovi pacchetti. L'endpoint crea un nuovo segreto di scrittura dal segreto di scrittura esistente come descritto nella Sezione 7.2 di [TLS13]. Questo utilizza la funzione KDF fornita da TLS con l'etichetta "quic ku". La chiave e l'IV corrispondenti sono creati da quel segreto come definito nella Sezione 5.1. La chiave di protezione dell'intestazione non viene aggiornata.
Ad esempio, per aggiornare le chiavi di scrittura con TLS 1.3, HKDF-Expand-Label viene utilizzato come:
secret_<n+1> = HKDF-Expand-Label(secret_`<n>`, "quic ku",
"", Hash.length)
L'endpoint alterna il valore del bit Key Phase e protegge tutti i pacchetti successivi utilizzando le chiavi e l'IV aggiornati.
Un endpoint NON DEVE (MUST NOT) avviare un aggiornamento delle chiavi prima che l'handshake sia confermato (Sezione 4.1.2). Un endpoint NON DEVE (MUST NOT) avviare un successivo aggiornamento delle chiavi a meno che non abbia ricevuto un acknowledgment per un pacchetto protetto utilizzando le chiavi della fase chiave corrente. Questo garantisce che le chiavi siano disponibili su entrambi i peer prima che un altro aggiornamento delle chiavi possa essere avviato. Questo può essere implementato tracciando il numero di pacchetto più basso inviato con ogni fase chiave e il numero di pacchetto acknowledgment più alto nello spazio 1-RTT. Una volta che quest'ultimo è maggiore o uguale al primo, un altro aggiornamento delle chiavi può essere avviato.
| Nota: Le chiavi per pacchetti diversi da 1-RTT non vengono aggiornate. Quelle chiavi sono derivate interamente | dallo stato dell'handshake TLS.
L'endpoint che avvia un aggiornamento delle chiavi aggiorna anche le chiavi che utilizza per ricevere pacchetti. Queste chiavi verranno utilizzate per elaborare i pacchetti inviati dal peer dopo l'aggiornamento.
Un endpoint DEVE (MUST) conservare le chiavi precedenti finché non ha deprotetto con successo un pacchetto inviato utilizzando le nuove chiavi. Un endpoint DOVREBBE (SHOULD) conservare le chiavi precedenti per un certo periodo dopo aver deprotetto un pacchetto inviato utilizzando le nuove chiavi. Eliminare le chiavi precedenti troppo presto può far sì che i pacchetti ritardati vengano scartati. Lo scarto dei pacchetti potrebbe essere interpretato dal peer come perdita di pacchetti e avere un impatto negativo sulle prestazioni.
6.2. Risposta Aggiornamento Chiavi (Responding to a Key Update)
Un peer può avviare un aggiornamento delle chiavi dopo aver ricevuto un acknowledgment per un pacchetto nella fase chiave corrente. Un endpoint rileva un aggiornamento delle chiavi quando elabora un pacchetto la cui fase chiave differisce dal valore utilizzato nell'ultimo pacchetto inviato. Per elaborare questo pacchetto, l'endpoint utilizza le chiavi di protezione dei pacchetti e l'IV successivi. Vedere Sezione 6.3 per considerazioni sulla generazione di queste chiavi.
Se il pacchetto può essere elaborato con successo utilizzando le chiavi e l'IV successivi, allora il peer ha avviato un aggiornamento delle chiavi. L'endpoint DEVE (MUST) aggiornare le sue chiavi di invio alla fase chiave corrispondente come descritto nella Sezione 6.1. Le chiavi di invio DEVONO (MUST) essere aggiornate prima di inviare un acknowledgment per il pacchetto ricevuto utilizzando le chiavi aggiornate. Riconoscendo il pacchetto che ha scatenato l'aggiornamento delle chiavi in un pacchetto protetto con le chiavi aggiornate, l'endpoint segnala che l'aggiornamento delle chiavi è completo.
Un endpoint PUÒ (MAY) differire l'invio del pacchetto o dell'acknowledgment secondo il normale comportamento di invio dei pacchetti. Non è necessario generare immediatamente un pacchetto in risposta a un aggiornamento delle chiavi. Il prossimo pacchetto inviato dall'endpoint utilizzerà le chiavi aggiornate. Il successivo pacchetto che contiene un acknowledgment completerà l'aggiornamento delle chiavi. Se un endpoint rileva un secondo aggiornamento prima di inviare un pacchetto con chiavi aggiornate contenente un acknowledgment per il pacchetto che ha avviato l'aggiornamento delle chiavi, indica che il peer ha aggiornato le chiavi due volte senza attendere un acknowledgment. Un endpoint PUÒ (MAY) trattare tali aggiornamenti chiave consecutivi come un errore di connessione di tipo KEY_UPDATE_ERROR.
Un endpoint che riceve un acknowledgment trasportato in un pacchetto protetto con chiavi precedenti, dove uno qualsiasi dei pacchetti acknowledgment erano protetti con chiavi più recenti, PUÒ (MAY) trattarlo come un errore di connessione di tipo KEY_UPDATE_ERROR. Questo indica che il peer ha ricevuto e acknowledgment un pacchetto che ha avviato l'aggiornamento delle chiavi, ma non ha aggiornato le chiavi in risposta.
6.3. Temporizzazione Generazione Chiavi Ricezione (Timing of Receive Key Generation)
Un endpoint che risponde a un apparente aggiornamento delle chiavi NON DEVE (MUST NOT) generare un segnale di canale laterale di temporizzazione che potrebbe indicare che il bit Key Phase non è valido (vedere Sezione 9.5). Se l'aggiornamento delle chiavi non è ancora consentito, l'endpoint può utilizzare una chiave casuale di protezione dei pacchetti al posto della chiave scartata. L'uso di una chiave casuale garantisce che il tentativo di rimuovere la protezione dei pacchetti non causi cambiamenti di temporizzazione e i pacchetti con un bit Key Phase non valido vengono rifiutati.
Il processo di creazione di nuove chiavi di protezione dei pacchetti per ricevere pacchetti potrebbe rivelare che si è verificato un aggiornamento delle chiavi. Un endpoint PUÒ (MAY) generare nuove chiavi come parte dell'elaborazione dei pacchetti, ma ciò creerebbe un segnale di temporizzazione che un attaccante potrebbe utilizzare per sapere quando si è verificato un aggiornamento delle chiavi e rivelare il valore del bit Key Phase.
Un endpoint DOVREBBE (SHOULD) avere normalmente sia le chiavi di protezione dei pacchetti di ricezione correnti che quelle successive. Durante un breve periodo dopo il completamento di un aggiornamento delle chiavi fino a un PTO, un endpoint PUÒ (MAY) differire la generazione del prossimo set di chiavi di protezione dei pacchetti di ricezione. Questo consente all'endpoint di conservare solo due set di chiavi di ricezione (vedere Sezione 6.5).
Una volta generate, il prossimo set di chiavi di protezione dei pacchetti DOVREBBE (SHOULD) essere conservato, anche se il pacchetto ricevuto viene successivamente scartato. I pacchetti che sembrano attivare un aggiornamento delle chiavi possono essere falsificati facilmente e, sebbene il processo di aggiornamento delle chiavi non richieda uno sforzo significativo, attivare questo processo può essere utilizzato da un attaccante per DoS.
Pertanto, un endpoint DEVE (MUST) essere in grado di conservare due set di chiavi di protezione dei pacchetti per la ricezione dei pacchetti: le chiavi correnti e quelle successive. Oltre a queste chiavi, conservare le chiavi precedenti potrebbe migliorare le prestazioni, ma non è richiesto.
6.4. Invio con Chiavi Aggiornate (Sending with Updated Keys)
Un endpoint non invia mai pacchetti protetti con chiavi precedenti. Solo le chiavi correnti vengono utilizzate. Le chiavi utilizzate per proteggere i pacchetti possono essere scartate immediatamente dopo il passaggio alle nuove chiavi.
I pacchetti con numeri di pacchetto superiori DEVONO (MUST) essere protetti con chiavi di protezione dei pacchetti uguali o più recenti rispetto ai pacchetti con numeri di pacchetto inferiori. Se un endpoint rileva che sta utilizzando nuove chiavi per un pacchetto con un numero di pacchetto inferiore rispetto a un pacchetto con un numero di pacchetto superiore, DEVE (MUST) trattarlo come un errore di connessione di tipo KEY_UPDATE_ERROR se deprotegge con successo utilizzando le chiavi precedenti.
6.5. Ricezione con Chiavi Diverse (Receiving with Different Keys)
Durante un aggiornamento delle chiavi, la ricezione di pacchetti può significare che i pacchetti protetti con chiavi precedenti sono ritardati sulla rete e arrivano. Conservare le vecchie chiavi di protezione dei pacchetti consente a questi pacchetti di essere elaborati con successo.
Poiché i pacchetti protetti con le chiavi della fase chiave successiva utilizzano lo stesso valore di fase chiave dei pacchetti protetti con le chiavi della fase chiave precedente, potrebbe essere necessario distinguere tra i due se è necessario elaborare pacchetti protetti con chiavi precedenti. Questo può essere fatto utilizzando il numero di pacchetto. Un numero di pacchetto ripristinato inferiore al numero di pacchetto nella fase chiave corrente utilizza le chiavi di protezione dei pacchetti precedenti. Un numero di pacchetto ripristinato superiore al numero di pacchetto nella fase chiave corrente richiede l'uso delle chiavi di protezione dei pacchetti successive.
È necessario prestare attenzione affinché qualsiasi processo per la selezione delle chiavi di protezione dei pacchetti precedenti, correnti o successive non esponga un canale laterale di temporizzazione che potrebbe rivelare quale chiave è stata utilizzata per rimuovere la protezione del pacchetto. Vedere Sezione 9.5 per ulteriori dettagli.
In alternativa, un endpoint può conservare solo due set di chiavi di protezione dei pacchetti, sostituendo le chiavi precedenti con le successive dopo un tempo sufficiente perché i pacchetti siano riordinati sulla rete. In questo caso, solo il bit Key Phase può essere utilizzato per selezionare le chiavi.
Un endpoint PUÒ (MAY) consentire un periodo di circa un Probe Timeout (PTO) (vedere [QUIC-RECOVERY]) dopo aver promosso il prossimo set di chiavi di ricezione a correnti prima di creare il successivo set di chiavi di protezione dei pacchetti. Queste chiavi aggiornate PÒ (MAY) sostituire le chiavi precedenti a quel punto. Con questo approccio, si noti che il PTO è una misura soggettiva e i peer potrebbero avere opinioni diverse su RTT. Si prevede che questo periodo sia abbastanza lungo che i pacchetti acknowledgment ma fuori ordine vengano dichiarati persi da un peer e abbastanza breve che un peer possa avviare un ulteriore aggiornamento delle chiavi.
Un endpoint dovrebbe considerare che il peer potrebbe non essere in grado di decifrare i pacchetti che avviano un aggiornamento delle chiavi durante il periodo in cui conserva le chiavi precedenti. Gli endpoint DOVREBBERO (SHOULD) attendere tre PTO dopo aver ricevuto un acknowledgment che riconosce il precedente aggiornamento delle chiavi prima di avviare un aggiornamento delle chiavi. Non lasciare abbastanza tempo potrebbe portare allo scarto dei pacchetti.
Un endpoint DOVREBBE (SHOULD) conservare le chiavi di lettura precedenti per non più di tre PTO dopo aver ricevuto un pacchetto protetto con chiavi più recenti. Dopo questo periodo, le chiavi di lettura precedenti e i loro corrispondenti segreti DOVREBBERO (SHOULD) essere scartati.
6.6. Limiti Uso AEAD (Limits on AEAD Usage)
Questo documento stabilisce limiti sull'uso degli algoritmi AEAD per garantire che un uso eccessivo quando utilizzato con QUIC non dia all'attaccante un vantaggio sproporzionato nell'attaccare la riservatezza e l'integrità delle comunicazioni.
I limiti di utilizzo definiti in TLS 1.3 esistono per prevenire attacchi alla riservatezza e si applicano alle applicazioni riuscite della protezione AEAD. Al contrario, la protezione dell'integrità nella crittografia autenticata dipende anche dal limitare i tentativi di falsificazione dei pacchetti. TLS raggiunge questo chiudendo la connessione dopo qualsiasi record che non supera un controllo di autenticazione. Al contrario, QUIC ignora i pacchetti che non possono essere autenticati, consentendo più tentativi di falsificazione.
QUIC considera separatamente i limiti di riservatezza e integrità dell'AEAD. Il limite di riservatezza si applica al numero di pacchetti crittografati con una determinata chiave. Il limite di integrità si applica al numero di pacchetti decrittografati in una determinata connessione. I dettagli sull'applicazione di questi limiti per ciascun algoritmo AEAD seguono di seguito.
Gli endpoint DEVONO (MUST) contare il numero di pacchetti crittografati per ogni set di chiavi. Se il numero totale di pacchetti crittografati con la stessa chiave supera il limite di riservatezza per l'AEAD selezionato, l'endpoint DEVE (MUST) interrompere l'uso di quelle chiavi. Gli endpoint DEVONO (MUST) avviare un aggiornamento delle chiavi prima di inviare pacchetti protetti che eccederebbero il limite di riservatezza consentito per l'AEAD selezionato. Se non è possibile un aggiornamento delle chiavi o se è stato raggiunto il limite di integrità, l'endpoint DEVE (MUST) interrompere l'uso della connessione e inviare solo un reset stateless in risposta alla ricezione di pacchetti. È RACCOMANDATO (RECOMMENDED) che gli endpoint chiudano immediatamente la connessione utilizzando un errore di connessione di tipo AEAD_LIMIT_REACHED prima di raggiungere uno stato in cui l'aggiornamento delle chiavi non è possibile.
Per AEAD_AES_128_GCM e AEAD_AES_256_GCM, il limite di riservatezza è 2^23 pacchetti crittografati (vedere Appendice B.1). Per AEAD_CHACHA20_POLY1305, il limite di riservatezza è maggiore del numero di pacchetti possibili (2^62) e può quindi essere ignorato. Per AEAD_AES_128_CCM, il limite di riservatezza è 2^21.5 pacchetti crittografati (vedere Appendice B.2). L'applicazione di questo limite riduce la probabilità che un attaccante possa distinguere l'AEAD utilizzato da una permutazione casuale (vedere [AEBounds], [ROBUST], [GCM-MU]).
Oltre a contare i pacchetti inviati, gli endpoint DEVONO (MUST) contare il numero di pacchetti ricevuti che non superano l'autenticazione durante la vita della connessione. Se il numero totale di pacchetti ricevuti che non superano l'autenticazione su tutte le chiavi in una connessione supera il limite di integrità per l'AEAD selezionato, l'endpoint DEVE (MUST) chiudere immediatamente la connessione utilizzando un errore di connessione di tipo AEAD_LIMIT_REACHED e non elaborare più pacchetti.
Per AEAD_AES_128_GCM e AEAD_AES_256_GCM, il limite di integrità è 2^52 pacchetti non validi (vedere Appendice B.1). Per AEAD_CHACHA20_POLY1305, il limite di integrità è 2^36 pacchetti non validi (vedere [AEBounds]). Per AEAD_AES_128_CCM, il limite di integrità è 2^21.5 pacchetti non validi (vedere Appendice B.2). L'applicazione di questo limite riduce la probabilità che un attaccante possa falsificare con successo i pacchetti (vedere [AEBounds], [ROBUST], [GCM-MU]).
Gli endpoint che limitano le dimensioni dei pacchetti PÒ (MAY) utilizzare limiti di riservatezza e integrità più elevati. Vedere Appendice B per ulteriori dettagli.
Analisi e specifiche future PÒ (MAY) rilassare i limiti di riservatezza o integrità per un AEAD.
Le cipher suite TLS specificate per l'uso con QUIC DEVONO (MUST) definire limiti di utilizzo per la funzione AEAD associata per preservare margini sia di riservatezza che di integrità. Cioè, DEVONO (MUST) specificare limiti sia sul numero di pacchetti che possono essere autenticati sia sui pacchetti che possono non superare l'autenticazione. Fornendo un riferimento a un'analisi basata sul valore (e alle ipotesi utilizzate in quell'analisi), è possibile regolare i limiti in base a diverse condizioni di utilizzo.
6.7. Codice Errore Aggiornamento Chiavi (Key Update Error Code)
Il codice di errore KEY_UPDATE_ERROR (0x0e) viene utilizzato per errori relativi all'aggiornamento delle chiavi.