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.