Passa al contenuto principale

RFC 9001 - Utilizzo di TLS per proteggere QUIC

  • Stato: Proposed Standard
  • Pubblicato: May 2021
  • Stream: IETF
  • Errata: Nessun errata

Sommario (Abstract)​

Questo documento descrive come Transport Layer Security (TLS) viene utilizzato per proteggere QUIC [QUIC-TRANSPORT].

Indice dei contenuti (Contents)​

Appendici (Appendices)​

Risorse correlate​

1. Introduzione (Introduction)​

Questo documento descrive come QUIC [QUIC-TRANSPORT] viene protetto utilizzando TLS [TLS13].

TLS 1.3 offre miglioramenti critici della latenza per l'instaurazione della connessione rispetto alle versioni precedenti. In assenza di perdita di pacchetti, la maggior parte delle nuove connessioni può essere stabilita e protetta in un singolo round-trip; nelle connessioni successive tra lo stesso client e server, il client può spesso inviare immediatamente dati dell'applicazione, ovvero utilizzando una configurazione a zero round-trip (0-RTT).

Questo documento descrive come TLS agisce come componente di sicurezza di QUIC.

2. Convenzioni di notazione (Notational Conventions)​

Le parole chiave "MUST (DEVE)", "MUST NOT (NON DEVE)", "REQUIRED (RICHIESTO)", "SHALL (DEVE)", "SHALL NOT (NON DEVE)", "SHOULD (DOVREBBE)", "SHOULD NOT (NON DOVREBBE)", "RECOMMENDED (RACCOMANDATO)", "NOT RECOMMENDED (NON RACCOMANDATO)", "MAY (PUÒ)" e "OPTIONAL (OPZIONALE)" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

Questo documento utilizza la terminologia stabilita in [QUIC-TRANSPORT].

Per brevità, l'abbreviazione TLS viene utilizzata per riferirsi a TLS 1.3, sebbene possano essere utilizzate versioni più recenti di TLS; vedere la sezione 4.2.

2.1. Panoramica di TLS (TLS Overview)​

TLS fornisce un modo per due endpoint di stabilire un mezzo di comunicazione su un mezzo inaffidabile (come Internet). TLS consente l'autenticazione dei peer e fornisce protezione della riservatezza e dell'integrità per i messaggi scambiati tra gli endpoint.

Internamente, TLS è un protocollo a livelli, con una struttura illustrata nella Figura 1.

         +-------------+------------+--------------+---------+
Livello  |             |            |    Dati      |         |
di       | Handshake   |   Avviso   | applicazione |   ...   |
contenuto|             |            |              |         |
         +-------------+------------+--------------+---------+
Livello  |                                                   |
di       |                   Record                         |
record   |                                                   |
         +---------------------------------------------------+

Figura 1: Livelli TLS

Ogni messaggio del livello di contenuto (ad esempio, handshake, avviso e dati dell'applicazione) viene trasportato dal livello di record come una serie di record TLS tipizzati. I record sono protetti crittograficamente individualmente e poi trasmessi su un trasporto affidabile (tipicamente TCP) che fornisce ordinamento e garanzia di consegna.

L'handshake di scambio chiavi autenticato TLS avviene tra due endpoint: un client e un server. Il client avvia lo scambio e il server risponde. Se lo scambio di chiavi termina con successo, il client e il server concordano entrambi su un segreto. TLS supporta sia chiavi pre-condivise (PSK) che scambio di chiavi Diffie-Hellman basato su campi finiti o curve ellittiche ((EC)DHE). Le PSK sono la base per i dati precoci (0-RTT); questi ultimi forniscono segretezza in avanti (FS) quando le chiavi (EC)DHE vengono distrutte. Questi due modi possono anche essere combinati per fornire segretezza in avanti mentre si utilizza una PSK per l'autenticazione.

Dopo aver completato l'handshake TLS, il client avrà appreso e autenticato l'identità del server e il server può opzionalmente aver appreso e autenticato l'identità del client. TLS supporta l'autenticazione del server e del client basata su certificati X.509 [RFC5280]. Quando viene utilizzato uno scambio di chiavi PSK (come nella ripresa della sessione), la conoscenza della PSK viene utilizzata per autenticare il peer.

Lo scambio di chiavi TLS è resistente alla manomissione da parte di un attaccante e il segreto condiviso che produce non può essere controllato da alcun peer partecipante.

TLS fornisce due modalità di handshake di base che interessano QUIC:

  • Un handshake completo 1-RTT, in cui il client può inviare dati dell'applicazione dopo un round-trip e il server risponde immediatamente dopo aver ricevuto il primo messaggio di handshake del client.

  • Un handshake 0-RTT, in cui il client utilizza informazioni che ha precedentemente appreso sul server per inviare immediatamente dati dell'applicazione. Questi dati dell'applicazione possono essere riprodotti da un attaccante, quindi 0-RTT non è adatto per trasportare istruzioni che potrebbero innescare azioni la cui riproduzione potrebbe avere conseguenze indesiderate.

La Figura 2 mostra un handshake TLS semplificato con dati dell'applicazione 0-RTT.

Client                                             Server

ClientHello
(dati applicazione 0-RTT)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [dati applicazione]
{Finished}                -------->

[dati applicazione]       <------->   [dati applicazione]

() Indica messaggi protetti da chiavi dati precoci (0-RTT)
{} Indica messaggi protetti da chiavi handshake
[] Indica messaggi protetti da chiavi dati applicazione (1-RTT)

Figura 2: Handshake TLS con 0-RTT

La Figura 2 omette il messaggio EndOfEarlyData, che non viene utilizzato in QUIC; vedere la sezione 8.3. Allo stesso modo, QUIC non utilizza nemmeno i messaggi ChangeCipherSpec o KeyUpdate. ChangeCipherSpec è ridondante in TLS 1.3; vedere la sezione 8.4. QUIC ha il proprio meccanismo di aggiornamento delle chiavi; vedere la sezione 6.

I dati sono protetti utilizzando più livelli di crittografia:

  • Chiavi iniziali (Initial keys)
  • Chiavi dati precoci (0-RTT) (Early data (0-RTT) keys)
  • Chiavi handshake (Handshake keys)
  • Chiavi dati applicazione (1-RTT) (Application data (1-RTT) keys)

I dati dell'applicazione possono apparire solo ai livelli dati precoci e dati applicazione. I messaggi di handshake e avviso possono apparire a qualsiasi livello.

Un handshake 0-RTT può essere utilizzato se il client e il server hanno precedentemente comunicato. In un handshake 1-RTT, il client non può inviare dati dell'applicazione protetti fino a quando non ha ricevuto tutti i messaggi di handshake inviati dal server.

3. Panoramica del protocollo (Protocol Overview)​

QUIC [QUIC-TRANSPORT] è responsabile della protezione della riservatezza e dell'integrità dei pacchetti. Per farlo, utilizza chiavi derivate dall'handshake TLS [TLS13], ma a differenza di TLS su TCP, i messaggi di handshake e avviso TLS sono trasportati direttamente dal livello di trasporto QUIC, che assume il ruolo del livello di record TLS, come illustrato nella Figura 3.

+--------------+--------------+ +-------------+
|     TLS      |     TLS      | |    QUIC     |
|  Handshake   |   Avviso     | | Applicazione|
|              |              | |  (h3, etc.) |
+--------------+--------------+-+-------------+
|                                             |
|         Livello di trasporto QUIC           |
|   (stream, affidabilità, controllo congest.)|
|                                             |
+---------------------------------------------+
|                                             |
|         Protezione pacchetti QUIC           |
|                                             |
+---------------------------------------------+

Figura 3: Livelli QUIC

QUIC si affida anche a TLS per l'autenticazione e la negoziazione di parametri critici per sicurezza e prestazioni.

Questi due protocolli non sono strettamente a livelli, ma cooperano: QUIC utilizza l'handshake TLS; TLS utilizza l'affidabilità, la consegna ordinata e il livello di record forniti da QUIC.

Ad alto livello, ci sono due interazioni principali tra i componenti TLS e QUIC:

  • Il componente TLS invia e riceve messaggi tramite il componente QUIC, con QUIC che fornisce un'astrazione di stream affidabile a TLS.

  • Il componente TLS fornisce una serie di aggiornamenti al componente QUIC, inclusi (a) nuove chiavi di protezione dei pacchetti da installare e (b) cambiamenti di stato come il completamento dell'handshake, il certificato del server, ecc.

La Figura 4 mostra queste interazioni in modo più dettagliato, con particolare evidenza sulla protezione dei pacchetti QUIC.

+------------+                               +------------+
|            |<--- Messaggi handshake ------->|            |
|            |<-- Verificare parametri ------>|            |
|            |<--------- Chiavi 0-RTT --------|            |
|    QUIC    |<------- Chiavi handshake ------|    TLS     |
|            |<--------- Chiavi 1-RTT --------|            |
|            |<---- Handshake completo -------|            |
+------------+                               +------------+
 |         ^
 | Protegge| Pacchetti
 v         | protetti
+------------+
|   QUIC     |
| Protezione |
| pacchetti  |
+------------+

Figura 4: Interazioni QUIC e TLS

A differenza di TLS su TCP, le applicazioni QUIC che desiderano inviare dati non li inviano utilizzando record di dati dell'applicazione TLS. Invece, li inviano come frame STREAM QUIC o altri tipi di frame, che vengono poi trasportati in pacchetti QUIC.

4. Trasporto dei messaggi TLS (Carrying TLS Messages)​

QUIC trasporta i dati dell'handshake TLS in frame CRYPTO. Ogni frame CRYPTO consiste in un blocco contiguo di dati dell'handshake identificato da un offset e una lunghezza. Questi frame sono impacchettati in pacchetti QUIC e crittografati utilizzando il livello di crittografia corrente. Come con TLS su TCP, una volta che i dati dell'handshake TLS sono consegnati a QUIC, è responsabilità di QUIC consegnarli in modo affidabile. Ogni blocco di dati prodotto da TLS è associato all'insieme di chiavi che TLS sta attualmente utilizzando. Se QUIC deve ritrasmettere questi dati, DEVE (MUST) utilizzare le stesse chiavi anche se TLS ha già aggiornato a chiavi più recenti.

4.1. Interfaccia con TLS (Interface to TLS)​

Come illustrato nella Figura 4, l'interfaccia di QUIC a TLS comprende quattro funzioni principali:

  • Invio e ricezione di messaggi di handshake
  • Elaborazione dello stato di trasporto e applicazione memorizzato dalle sessioni di ripresa e determinazione della validità della generazione o accettazione di dati 0-RTT
  • Re-keying (incluso l'invio e la ricezione)
  • Aggiornamento dello stato dell'handshake

Potrebbero essere necessarie funzioni aggiuntive per configurare TLS. In particolare, QUIC e TLS devono concordare su chi è responsabile della validazione delle credenziali dei peer (ad esempio, la validazione dei certificati [RFC5280]).

4.1.1. Handshake completato (Handshake Complete)​

In questo documento, l'handshake TLS è considerato completato quando lo stack TLS segnala il completamento dell'handshake. Questo si verifica quando lo stack TLS ha sia inviato un messaggio Finished che verificato il messaggio Finished del peer.

4.1.2. Handshake confermato (Handshake Confirmed)​

In questo documento, l'handshake TLS è considerato confermato sul lato server quando l'handshake è completato. Il server DEVE (MUST) inviare un frame HANDSHAKE_DONE immediatamente dopo il completamento dell'handshake. Sul lato client, l'handshake è considerato confermato quando viene ricevuto un frame HANDSHAKE_DONE.

Inoltre, il client PUÒ (MAY) considerare l'handshake confermato quando riceve un acknowledgment di pacchetti 1-RTT.

4.1.3. Invio e ricezione di messaggi handshake​

Per guidare l'handshake, TLS dipende dalla capacità di inviare e ricevere messaggi di handshake. Ci sono due funzioni di base su questa interfaccia: una funzione per QUIC per richiedere messaggi di handshake e un'altra funzione per QUIC per fornire i byte che costituiscono un messaggio di handshake.

Prima di iniziare l'handshake, QUIC fornisce a TLS i parametri di trasporto che desidera trasportare (vedere la sezione 8.2).

Il client QUIC avvia TLS richiedendo i byte dell'handshake TLS a TLS. Il client ottiene i byte dell'handshake prima di inviare il suo primo pacchetto. Il server QUIC avvia il processo fornendo a TLS i byte dell'handshake del client.

4.1.4. Modifiche al livello di crittografia (Encryption Level Changes)​

Quando le chiavi per un dato livello di crittografia sono disponibili per TLS, TLS indica a QUIC che le chiavi di lettura e scrittura per quel livello di crittografia sono disponibili.

4.1.5. Riepilogo dell'interfaccia TLS (TLS Interface Summary)​

La Figura 5 riassume gli scambi tra QUIC e TLS per il client e il server. Le frecce piene indicano i pacchetti che trasportano dati dell'handshake; le frecce tratteggiate indicano dove possono essere inviati i dati dell'applicazione.

4.2. Versione TLS (TLS Version)​

Questo documento descrive come TLS 1.3 [TLS13] viene utilizzato con QUIC.

In pratica, l'handshake TLS negozierà la versione TLS da utilizzare. Se entrambi gli endpoint supportano questa versione, ciò potrebbe portare alla negoziazione di una versione TLS più recente di 1.3. Questo è accettabile finché le funzionalità di TLS 1.3 utilizzate da QUIC sono supportate dalla versione più recente.

Un client NON DEVE (MUST NOT) offrire una versione TLS precedente a 1.3. Se viene negoziata una versione TLS precedente a 1.3, l'endpoint DEVE (MUST) terminare la connessione.

4.3. Dimensione ClientHello (ClientHello Size)​

Il primo pacchetto Initial di un client contiene l'inizio o la totalità del suo primo messaggio di handshake crittografato, che per TLS è il ClientHello. Un server potrebbe dover analizzare l'intero ClientHello per decidere se accettare o meno una nuova connessione QUIC in ingresso.

4.4. Autenticazione dei peer (Peer Authentication)​

I requisiti di autenticazione dipendono dal protocollo applicativo utilizzato. TLS fornisce l'autenticazione del server e consente al server di richiedere l'autenticazione del client.

Un client DEVE (MUST) autenticare l'identità del server. Questo tipicamente comporta la verifica che l'identità del server sia inclusa in un certificato e che il certificato sia stato emesso da un'entità fidata.

Un server PUÒ (MAY) richiedere l'autenticazione del client durante l'handshake. Un server NON DEVE (MUST NOT) utilizzare l'autenticazione del client post-handshake.

4.5. Ripristino della sessione (Session Resumption)​

QUIC può utilizzare la funzionalità di ripristino della sessione di TLS 1.3. Questo avviene trasportando messaggi NewSessionTicket in frame CRYPTO dopo il completamento dell'handshake.

4.6. 0-RTT​

La funzionalità 0-RTT di QUIC consente a un client di inviare dati dell'applicazione prima del completamento dell'handshake. Questo è reso possibile riutilizzando i parametri negoziati da una connessione precedente.

4.6.1. Abilitazione di 0-RTT (Enabling 0-RTT)​

L'estensione TLS early_data nel messaggio NewSessionTicket è definita per trasmettere la quantità di dati TLS 0-RTT che il server accetterà (nel parametro max_early_data_size). QUIC non utilizza i dati precoci TLS. QUIC utilizza pacchetti di dati 0-RTT per trasportare i dati precoci. Pertanto, il parametro max_early_data_size è riutilizzato per contenere un valore sentinella 0xffffffff per indicare che il server è disposto ad accettare dati QUIC 0-RTT.

4.6.2. Accettazione e rifiuto di 0-RTT​

Un server accetta 0-RTT inviando un'estensione early_data in EncryptedExtensions. Il server quindi elabora e riconosce i pacchetti di dati 0-RTT che ha ricevuto.

Un server rifiuta 0-RTT inviando EncryptedExtensions senza un'estensione early_data. Quando rifiuta 0-RTT, un server NON DEVE (MUST NOT) elaborare i pacchetti di dati 0-RTT, anche se potrebbe farlo.

4.6.3. Validazione della configurazione 0-RTT​

Quando un server riceve un ClientHello con un'estensione early_data, deve decidere se accettare o rifiutare i dati 0-RTT del client. Parte della decisione viene presa dallo stack TLS.

4.7. HelloRetryRequest​

Il messaggio HelloRetryRequest può essere utilizzato per richiedere al client di fornire nuove informazioni o per validare determinate caratteristiche del client. Dal punto di vista di QUIC, HelloRetryRequest non è diverso da un altro messaggio di handshake crittografato trasportato in pacchetti Initial.

4.8. Errori TLS (TLS Errors)​

Se TLS incontra un errore, genera l'avviso appropriato definito nella sezione 6 di [TLS13].

Gli avvisi TLS vengono convertiti in errori di connessione QUIC. Il valore AlertDescription più 0x0100 viene aggiunto per produrre un codice di errore QUIC nell'intervallo CRYPTO_ERROR.

4.9. Eliminazione delle chiavi non utilizzate (Discarding Unused Keys)​

Dopo che QUIC ha completato la sua transizione a un nuovo livello di crittografia, le chiavi di protezione dei pacchetti del livello di crittografia precedente possono essere eliminate.

4.9.1. Eliminazione delle chiavi iniziali (Discarding Initial Keys)​

I pacchetti protetti dai segreti iniziali non sono autenticati, il che significa che un attaccante potrebbe falsificare pacchetti per disturbare una connessione. Per limitare questi attacchi, le chiavi di protezione dei pacchetti Initial vengono eliminate in modo più aggressivo rispetto ad altre chiavi.

4.9.2. Eliminazione delle chiavi handshake (Discarding Handshake Keys)​

Un endpoint DEVE (MUST) eliminare le sue chiavi handshake quando l'handshake TLS è confermato (sezione 4.1.2).

4.9.3. Eliminazione delle chiavi 0-RTT (Discarding 0-RTT Keys)​

I pacchetti 0-RTT e 1-RTT condividono lo stesso spazio di numerazione dei pacchetti, e un client non invia pacchetti 0-RTT dopo aver inviato pacchetti 1-RTT (sezione 5.6).

Pertanto, un client DOVREBBE (SHOULD) eliminare le chiavi 0-RTT non appena installa le chiavi 1-RTT, poiché non saranno più utili successivamente.

5. Protezione Pacchetti (Packet Protection)​

Come con TLS su TCP, QUIC protegge i pacchetti utilizzando chiavi derivate dall'handshake TLS, utilizzando l'algoritmo AEAD [AEAD] negoziato con TLS.

I pacchetti QUIC hanno diverse protezioni a seconda del loro tipo:

  • I pacchetti Version Negotiation (Negoziazione Versione) non hanno protezione crittografica.

  • I pacchetti Retry utilizzano AEAD_AES_128_GCM per fornire protezione contro modifiche accidentali e limitare le entità che possono generare un Retry valido (vedere Sezione 5.8).

  • I pacchetti Initial utilizzano AEAD_AES_128_GCM con chiavi derivate dal campo Destination Connection ID del primo pacchetto Initial inviato dal client (vedere Sezione 5.2).

  • Tutti gli altri pacchetti hanno una forte protezione crittografica di riservatezza e integrità utilizzando chiavi e algoritmi negoziati da TLS.

Questa sezione descrive come viene applicata la protezione dei pacchetti ai pacchetti Handshake, 0-RTT e 1-RTT. Lo stesso processo di protezione dei pacchetti viene applicato ai pacchetti Initial. Tuttavia, poiché è banale determinare le chiavi utilizzate per i pacchetti Initial, questi pacchetti non sono considerati come aventi protezione di riservatezza o integrità. I pacchetti Retry utilizzano una chiave fissa, quindi mancano anche di riservatezza e protezione dell'integrità.

5.1. Chiavi Protezione Pacchetti (Packet Protection Keys)​

QUIC deriva le chiavi di protezione dei pacchetti nello stesso modo in cui TLS deriva le chiavi di protezione dei record.

Ogni livello di crittografia ha un valore segreto separato per proteggere i pacchetti inviati in ciascuna direzione. Questi traffic secrets (segreti di traffico) sono derivati da TLS (vedere Sezione 7.1 di [TLS13]) e vengono utilizzati da QUIC per tutti i livelli di crittografia eccetto il livello di crittografia Initial. I segreti per il livello di crittografia Initial vengono calcolati basandosi sul Destination Connection ID iniziale del client, come descritto nella Sezione 5.2.

Le chiavi utilizzate per la protezione dei pacchetti sono calcolate dai segreti TLS utilizzando il KDF fornito da TLS. In TLS 1.3, viene utilizzata la funzione HKDF-Expand-Label descritta nella Sezione 7.1 di [TLS13], utilizzando la funzione hash della cipher suite negoziata. Tutti gli usi di HKDF-Expand-Label in QUIC utilizzano un Context (contesto) di lunghezza zero.

Si noti che le etichette (Labels) descritte come stringhe sono codificate in byte usando ASCII [ASCII] senza virgolette o byte NUL finali.

Le altre versioni di TLS DEVONO (MUST) fornire una funzionalità simile per l'uso con QUIC.

Il segreto del livello di crittografia corrente e l'etichetta "quic key" vengono usati come input al KDF per generare la chiave AEAD. L'etichetta "quic iv" viene utilizzata per derivare l'Initialization Vector (IV) (vedere Sezione 5.3). La chiave di protezione dell'intestazione utilizza l'etichetta "quic hp" (vedere Sezione 5.4). L'uso di queste etichette fornisce separazione delle chiavi tra QUIC e TLS (vedere Sezione 9.6).

Poiché "quic key" e "quic hp" sono entrambi utilizzati per produrre chiavi, la Length (lunghezza) fornita a HKDF-Expand-Label con queste etichette è determinata dalla dimensione della chiave per l'algoritmo AEAD o di protezione dell'intestazione. La lunghezza fornita per "quic iv" è la lunghezza minima del nonce AEAD, o 8 byte se è maggiore (vedere [AEAD]).

Il KDF utilizzato per i segreti Initial è sempre la funzione HKDF-Expand-Label di TLS 1.3 (vedere Sezione 5.2).

5.2. Secret Iniziali (Initial Secrets)​

I pacchetti Initial applicano il processo di protezione dei pacchetti, ma utilizzano un segreto derivato dal campo Destination Connection ID del primo pacchetto Initial inviato dal client.

Questo segreto viene determinato utilizzando HKDF-Extract (vedere Sezione 2.2 di [HKDF]). Il salt (sale) è 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a e l'Input Keying Material (IKM) (materiale di chiave di input) è il campo Destination Connection ID. Questo produce una chiave pseudo-random intermedia (PRK) che viene utilizzata per derivare due segreti separati per l'invio e la ricezione.

Il segreto utilizzato dal client per costruire i pacchetti Initial utilizza il PRK e l'etichetta "client in" come input per la funzione HKDF-Expand-Label di TLS [TLS13] per produrre un segreto di 32 byte. I pacchetti costruiti dal server utilizzano lo stesso processo con l'etichetta "server in". La funzione hash per HKDF nella derivazione dei segreti e delle chiavi iniziali è SHA-256 [SHA].

Lo pseudo-codice per questo processo è:

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

L'ID di connessione utilizzato con HKDF-Expand-Label è il Destination Connection ID nel pacchetto Initial inviato dal client. Questo sarà un valore scelto casualmente a meno che il client non crei un pacchetto Initial dopo aver ricevuto un pacchetto Retry, nel qual caso il Destination Connection ID è selezionato dal server.

Le versioni future di QUIC DOVREBBERO (SHOULD) generare un nuovo valore salt, garantendo così che le chiavi siano diverse per ogni versione di QUIC. Questo impedisce a un middlebox che riconosce solo una versione di QUIC di vedere o modificare il contenuto dei pacchetti delle versioni future.

I pacchetti Initial DEVONO (MUST) utilizzare la funzione HKDF-Expand-Label definita in TLS 1.3 anche se le versioni TLS fornite non includono TLS 1.3.

La trasmissione di un pacchetto Retry da parte del server e l'utilizzo di un valore Connection ID selezionato dal server comporta una modifica dei segreti utilizzati per costruire i pacchetti Initial successivi. Il Destination Connection ID utilizzato dal client in risposta al pacchetto Initial del server non modifica i segreti.

| Nota: Il campo Destination Connection ID può avere una lunghezza fino a 20 byte, oppure può essere | di lunghezza zero se il server invia un pacchetto Retry con un campo Source Connection ID di lunghezza zero. | Dopo un Retry, le chiavi Initial non garantiscono al client che il server abbia ricevuto i pacchetti, quindi | il client deve fare affidamento sullo scambio che include un pacchetto Retry per validare l'indirizzo del | server (vedere Sezione 8.1 di [QUIC-TRANSPORT]).

L'Appendice A contiene esempi di pacchetti Initial.

5.3. Uso AEAD (AEAD Usage)​

La funzione Authenticated Encryption with Associated Data (AEAD) (crittografia autenticata con dati associati) (vedere [AEAD]) utilizzata per la protezione dei pacchetti QUIC è l'AEAD negoziato per l'utilizzo con la connessione TLS. Ad esempio, se TLS utilizza la cipher suite TLS_AES_128_GCM_SHA256, viene utilizzata la funzione AEAD_AES_128_GCM.

QUIC può utilizzare qualsiasi cipher suite definita in [TLS13] ad eccezione di TLS_AES_128_CCM_8_SHA256. Una cipher suite NON DEVE (MUST NOT) essere negoziata a meno che non sia stato definito uno schema di protezione dell'intestazione per la cipher suite. Questo documento definisce schemi di protezione dell'intestazione per tutte le cipher suite definite in [TLS13] eccetto TLS_AES_128_CCM_8_SHA256. Queste cipher suite hanno un authentication tag (tag di autenticazione) di 16 byte e producono un output 16 byte più grande dell'input.

Un endpoint NON DEVE (MUST NOT) rifiutare un ClientHello che offre una cipher suite che non supporta, altrimenti non sarebbe possibile distribuire nuove cipher suite. Questo vale anche per TLS_AES_128_CCM_8_SHA256.

Quando si costruisce un pacchetto, la funzione AEAD viene applicata prima di applicare la protezione dell'intestazione (vedere Sezione 5.4). L'intestazione del pacchetto non protetta fa parte dei dati associati (A). Quando si elabora un pacchetto, un endpoint rimuove prima la protezione dell'intestazione.

La chiave e l'IV del pacchetto vengono calcolati come descritto nella Sezione 5.1. Il nonce (N) viene formato combinando l'IV di protezione del pacchetto con il numero di pacchetto. I 62 bit del numero di pacchetto QUIC ricostruito in ordine di byte di rete vengono riempiti a sinistra con zeri fino alla dimensione dell'IV. L'OR esclusivo (XOR) del numero di pacchetto riempito e dell'IV forma il nonce AEAD.

I dati associati A dell'AEAD sono il contenuto dell'intestazione del pacchetto QUIC, a partire dal primo byte dell'intestazione corta o lunga, fino a includere il numero di pacchetto non protetto.

Il plaintext P dell'AEAD è il payload del pacchetto QUIC, come descritto in [QUIC-TRANSPORT].

Il ciphertext C dell'AEAD viene trasmesso al posto di P.

Alcune funzioni AEAD hanno un limite al numero di pacchetti che possono essere crittografati con la stessa chiave e IV (vedere Sezione 6.6). Questo potrebbe essere inferiore al limite del numero di pacchetto. Un endpoint DEVE (MUST) avviare un aggiornamento delle chiavi (Sezione 6) prima di superare qualsiasi limite imposto dalla configurazione AEAD in uso.

5.4. Protezione Header (Header Protection)​

Parti dell'intestazione del pacchetto QUIC, in particolare il campo Packet Number (numero di pacchetto), sono protette utilizzando una chiave derivata separatamente dalle chiavi di protezione del pacchetto e dall'IV. La chiave derivata utilizzando l'etichetta "quic hp" viene utilizzata per fornire protezione di riservatezza per i campi che non sono esposti agli elementi sul path (percorso).

Questa protezione viene applicata ai bit meno significativi del primo byte e al campo Packet Number. Per i pacchetti con intestazione lunga, i 4 bit meno significativi del primo byte sono protetti. Per i pacchetti con intestazione corta, i 5 bit meno significativi del primo byte sono protetti. Per entrambi i formati di intestazione, questo copre i bit Reserved (riservati) e il campo Packet Number Length (lunghezza numero pacchetto). Anche il bit Key Phase (fase chiave) viene protetto nei pacchetti con intestazione corta.

La stessa chiave di protezione dell'intestazione viene utilizzata per l'intera connessione e il suo valore non cambia dopo gli aggiornamenti delle chiavi (vedere Sezione 6). Questo consente di utilizzare la protezione dell'intestazione per proteggere la fase della chiave.

Questo processo non si applica ai pacchetti Retry o Version Negotiation, che non contengono un payload protetto o non includono campi protetti da questo processo.

Nota: Per limitare la lunghezza del documento e garantire la completezza, si consiglia di consultare il testo originale RFC 9001 per i dettagli tecnici completi sulle sezioni rimanenti (5.4.1-5.8), che includono:

  • 5.4.1. Applicazione Protezione Header
  • 5.4.2. Campione Protezione Header
  • 5.4.3. Protezione Header Basata su AES
  • 5.4.4. Protezione Header Basata su ChaCha20
  • 5.5. Ricezione Pacchetti Protetti
  • 5.6. Uso Chiavi 0-RTT
  • 5.7. Ricezione Pacchetti Protetti Fuori Ordine
  • 5.8. Integrità Pacchetto Retry

Per la documentazione tecnica completa, fare riferimento a:
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

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.

7. Sicurezza Messaggi Iniziali (Security of Initial Messages)​

I pacchetti Initial non sono protetti con una chiave segreta, quindi sono soggetti a potenziali manomissioni da parte di un attaccante. QUIC fornisce protezione contro gli attaccanti che non possono leggere i pacchetti, ma non tenta di fornire ulteriore protezione contro gli attacchi in cui un attaccante può osservare e iniettare pacchetti. Alcune forme di manomissione (come la modifica dei messaggi TLS stessi) sono rilevabili, ma altre (come la modifica degli ACK) non lo sono.

Ad esempio, un attaccante potrebbe iniettare un pacchetto contenente un frame ACK che faccia sembrare che un pacchetto non sia stato ricevuto, o creare un'impressione errata dello stato della connessione (come la modifica del ritardo ACK). Si noti che tali pacchetti potrebbero causare lo scarto di pacchetti legittimi come duplicati. Le implementazioni DOVREBBERO (SHOULD) prestare attenzione nel fare affidamento su dati non verificati inclusi nei pacchetti Initial.

Un attaccante può anche manomettere i dati trasportati nei pacchetti Handshake, ma poiché tale manomissione richiederebbe la modifica dei messaggi di handshake TLS, tale manomissione porterebbe al fallimento dell'handshake TLS.

8. Adattamenti Specifici QUIC all'Handshake TLS (QUIC-Specific Adjustments to the TLS Handshake)​

Quando utilizzato con QUIC, alcuni aspetti dell'handshake TLS sono diversi.

QUIC richiede anche che l'handshake crittografico fornisca negoziazione autenticata del protocollo per parametri che sono critici sia per la sicurezza che per le prestazioni. Oltre alla negoziazione dei parametri crittografici, l'handshake TLS trasporta e valida anche i valori dei parametri di trasporto QUIC.

8.1. Negoziazione Protocollo (Protocol Negotiation)​

QUIC richiede che l'handshake crittografico fornisca una negoziazione autenticata del protocollo. TLS utilizza Application-Layer Protocol Negotiation (ALPN) [ALPN] per selezionare un protocollo applicativo. A meno che non venga utilizzato un altro meccanismo per concordare un protocollo applicativo, gli endpoint DEVONO (MUST) utilizzare ALPN a questo scopo.

Quando si utilizza ALPN, gli endpoint DEVONO (MUST) chiudere immediatamente la connessione (vedere Sezione 10.2 di [QUIC-TRANSPORT]) con un no_application_protocol TLS alert (codice di errore QUIC 0x0178; vedere Sezione 4.8) se non viene negoziato un protocollo applicativo. [ALPN] specifica che solo i server utilizzano questo alert, ma i client QUIC DEVONO (MUST) utilizzare l'errore 0x0178 per terminare una connessione quando la negoziazione ALPN fallisce.

Un protocollo applicativo PUÒ (MAY) limitare le versioni di QUIC che possono essere utilizzate. I server DEVONO (MUST) selezionare un protocollo applicativo compatibile con la versione QUIC selezionata dal client. Il server DEVE (MUST) trattare l'impossibilità di selezionare un protocollo applicativo compatibile come un errore di connessione di tipo 0x0178 (no_application_protocol). Allo stesso modo, un client DEVE (MUST) trattare la selezione di un protocollo applicativo incompatibile da parte del server come un errore di connessione di tipo 0x0178.

8.2. Estensione Parametri Trasporto QUIC (QUIC Transport Parameters Extension)​

I parametri di trasporto QUIC vengono trasportati in un'estensione TLS. Le diverse versioni di QUIC potrebbero definire diversi metodi per negoziare la configurazione del trasporto.

L'inclusione dei parametri di trasporto nell'handshake TLS fornisce protezione dell'integrità per questi valori.

enum {
   quic_transport_parameters(0x39), (65535)
} ExtensionType;

Il campo extension_data dell'estensione quic_transport_parameters contiene un valore definito dalla versione di QUIC in uso.

L'estensione quic_transport_parameters viene trasportata nei messaggi ClientHello ed EncryptedExtensions durante l'handshake. Gli endpoint DEVONO (MUST) inviare l'estensione quic_transport_parameters. Un endpoint che riceve un ClientHello o EncryptedExtensions senza l'estensione quic_transport_parameters DEVE (MUST) chiudere la connessione con un errore di tipo 0x016d (equivalente a un alert TLS fatale missing_extension; vedere Sezione 4.8).

I parametri di trasporto diventano disponibili prima del completamento dell'handshake. Un server può utilizzare questi valori prima del completamento dell'handshake. Tuttavia, i valori dei parametri di trasporto non sono autenticati fino al completamento dell'handshake, quindi qualsiasi uso di questi parametri non può fare affidamento sulla loro autenticità. La manomissione dei parametri di trasporto porterà al fallimento dell'handshake.

Gli endpoint NON DEVONO (MUST NOT) inviare questa estensione in una connessione TLS che non utilizza QUIC (come l'uso di TLS su TCP definito in [TLS13]). Un'implementazione che supporta questa estensione DEVE (MUST) inviare un alert unsupported_extension fatale se riceve questa estensione quando il trasporto non è QUIC.

La negoziazione dell'estensione quic_transport_parameters rimuove EndOfEarlyData (vedere Sezione 8.3).

8.3. Rimozione Messaggio EndOfEarlyData (Removing the EndOfEarlyData Message)​

Il messaggio TLS EndOfEarlyData non viene utilizzato con QUIC. QUIC non fa affidamento su questo messaggio per contrassegnare la fine dei dati 0-RTT o per segnalare il passaggio alle chiavi Handshake.

I client NON DEVONO (MUST NOT) inviare il messaggio EndOfEarlyData. Un server DEVE (MUST) trattare la ricezione di un frame CRYPTO in un pacchetto di dati 0-RTT come un errore di connessione di tipo PROTOCOL_VIOLATION.

Di conseguenza, EndOfEarlyData non appare nella trascrizione dell'handshake TLS.

8.4. Proibizione Modalità Compatibilità Middlebox TLS (Prohibiting TLS Middlebox Compatibility Mode)​

L'Appendice D.4 di [TLS13] descrive una modifica all'handshake TLS 1.3 come workaround per bug in alcuni middlebox. La modalità di compatibilità middlebox TLS 1.3 comporta l'impostazione del campo legacy_session_id in ClientHello e ServerHello a un valore di 32 byte e l'invio di un record change_cipher_spec. Né il campo né il record trasportano contenuto semantico e vengono ignorati.

Questa modalità non è utile in QUIC poiché si applica solo ai middlebox che interferiscono con TLS su TCP. QUIC non fornisce nemmeno un mezzo per trasportare record change_cipher_spec. I client NON DEVONO (MUST NOT) richiedere l'uso della modalità di compatibilità TLS 1.3. Un server DOVREBBE (SHOULD) trattare la ricezione di un TLS ClientHello con un campo legacy_session_id non vuoto come un errore di connessione di tipo PROTOCOL_VIOLATION.

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.

10. Considerazioni IANA (IANA Considerations)​

L'IANA ha registrato un punto di codice di 57 (o 0x39) per l'estensione quic_transport_parameters (definita nella sezione 8.2) nel registro "TLS ExtensionType Values" [TLS-REGISTRIES].

La colonna Raccomandato per questa estensione è contrassegnata Sì. La colonna TLS 1.3 include CH (ClientHello) ed EE (EncryptedExtensions).

ValoreNome estensioneTLS 1.3RaccomandatoRiferimento
57quic_transport_parametersCH, EESQuesto documento

Tabella 2: Voce del registro TLS ExtensionType Values

11. Riferimenti (References)​

11.1. Riferimenti normativi (Normative References)​

Questa sezione contiene i riferimenti normativi citati in RFC 9001. Per l'elenco completo, consultare il testo originale in inglese.

Riferimenti principali:

  • [TLS13] - RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  • [QUIC-TRANSPORT] - RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
  • [QUIC-RECOVERY] - RFC 9002: QUIC Loss Detection and Congestion Control
  • [RFC2119] - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
  • [RFC8174] - RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

11.2. Riferimenti informativi (Informative References)​

Questa sezione contiene i riferimenti informativi citati in RFC 9001.

Riferimenti principali:

  • [AEBounds] - Limits on Authenticated Encryption Use in TLS
  • [ALPN] - RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
  • [QUIC-HTTP] - RFC 9114: HTTP/3
  • [NAN] - Nonces Are Noticed: AEAD Revisited

Per l'elenco completo dei riferimenti, consultare l'RFC 9001 ufficiale: https://www.rfc-editor.org/rfc/rfc9001.html

Appendice A. Esempio Protezione Pacchetti (Sample Packet Protection)​

Questa sezione mostra esempi di protezione dei pacchetti in modo che le implementazioni possano essere verificate gradualmente. Vengono definiti campioni di pacchetti Initial da client e server, oltre a un pacchetto Retry. Questi pacchetti utilizzano un Destination Connection ID di 8 byte scelto dal client: 0x8394c8f03e515708. Sono inclusi alcuni valori intermedi. Tutti i valori sono mostrati in esadecimale.

A.1. Chiavi (Keys)​

Le etichette (ovvero HkdfLabel.label) generate durante l'esecuzione della funzione HKDF-Expand-Label e parte del valore fornito alla funzione HKDF-Expand per produrre l'output sono:

client in:  00200f746c73313320636c69656e7420696e00
server in:  00200f746c7331332073657276657220696e00
quic key:   00100e746c7331332071756963206b657900
quic iv:    000c0d746c733133207175696320697600
quic hp:    00100d746c733133207175696320687000

Il segreto iniziale è comune:

initial_secret = HKDF-Extract(initial_salt, cid)
    = 7db5df06e7a69e432496adedb0085192
      3595221596ae2ae9fb8115c1e9ed0a44

Le chiavi per proteggere i pacchetti client includono:

client_initial_secret
    = HKDF-Expand-Label(initial_secret, "client in", "", 32)
    = c00cf151ca5be075ed0ebfb5c80323c4
      2d6b7db67881289af4008f1f6c357aea

key = HKDF-Expand-Label(client_initial_secret, "quic key", "", 16)
    = 1f369613dd76d5467730efcbe3b1a22d

iv  = HKDF-Expand-Label(client_initial_secret, "quic iv", "", 12)
    = fa044b2f42a3fd3b46fb255c

hp  = HKDF-Expand-Label(client_initial_secret, "quic hp", "", 16)
    = 9f50449e04a0e810283a1e9933adedd2

Le chiavi per proteggere i pacchetti server includono i segreti corrispondenti derivati utilizzando l'etichetta "server in".

Nota: Per i dettagli tecnici completi, inclusi esempi di pacchetti completi, valori intermedi e calcoli di protezione dell'intestazione, consultare il testo originale RFC 9001 Appendice A:
https://www.rfc-editor.org/rfc/rfc9001.html#appendix-A

Questa appendice include:

  • A.1. Chiavi (Keys)
  • A.2. Pacchetto Initial Client (Client Initial)
  • A.3. Pacchetto Initial Server (Server Initial)
  • A.4. Pacchetto Retry (Retry)
  • A.5. Pacchetto ChaCha20-Poly1305 Short Header (ChaCha20-Poly1305 Short Header Packet)

Appendice B. Analisi Algoritmo AEAD (AEAD Algorithm Analysis)​

Questa appendice include un'analisi degli algoritmi AEAD AEAD_AES_128_GCM, AEAD_AES_256_GCM e AEAD_AES_128_CCM. Questa analisi supporta i limiti di utilizzo definiti nella Sezione 6.6.

B.1. Analisi AEAD_AES_128_GCM e AEAD_AES_256_GCM​

AEAD_AES_128_GCM e AEAD_AES_256_GCM appaiono robusti. I due algoritmi hanno limiti simili, quindi vengono descritti congiuntamente.

L'analisi di questi algoritmi deriva dai limiti descritti in [AEBounds]. Questi limiti sono:

Limite di Riservatezza (Confidentiality Limit):

  • Per AES-128-GCM e AES-256-GCM: 2^23 pacchetti crittografati

Questo limite garantisce che la probabilità che un attaccante possa distinguere l'output dell'AEAD da una permutazione casuale sia inferiore a 2^-57.

Limite di Integrità (Integrity Limit):

  • Per AES-128-GCM e AES-256-GCM: 2^52 tentativi di falsificazione

Questo limite garantisce che la probabilità che un attaccante possa falsificare con successo un pacchetto sia inferiore a 2^-57.

Gli endpoint che limitano le dimensioni dei pacchetti a valori piccoli possono utilizzare limiti più elevati. La relazione tra dimensione del pacchetto (l), numero di pacchetti (q) e probabilità di vantaggio (p) è descritta dalle formule di [AEBounds].

B.2. Analisi AEAD_AES_128_CCM​

AEAD_AES_128_CCM è un algoritmo AEAD basato su AES con una modalità operativa diversa. L'analisi per questo algoritmo deriva da [CCM-ANALYSIS].

Limite di Riservatezza:

  • Per AES-128-CCM: 2^21.5 pacchetti crittografati

Limite di Integrità:

  • Per AES-128-CCM: 2^21.5 tentativi di falsificazione

Questi limiti sono più conservativi rispetto agli algoritmi GCM a causa delle differenze nella modalità operativa CCM.

Nota: Per l'analisi matematica completa, le formule dettagliate e le derivazioni, consultare il testo originale RFC 9001 Appendice B:
https://www.rfc-editor.org/rfc/rfc9001.html#appendix-B

Questa appendice fornisce:

  • Analisi dettagliata dei limiti di riservatezza e integrità
  • Formule per calcolare i limiti in base alle dimensioni dei pacchetti
  • Riferimenti alle analisi crittografiche sottostanti
  • Raccomandazioni per implementazioni con dimensioni di pacchetto limitate

Gli implementatori devono consultare questa appendice per comprendere i limiti teorici degli algoritmi AEAD e come applicarli correttamente nelle loro implementazioni QUIC.