Passa al contenuto principale

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.

Ultimo aggiornamento il