Passa al contenuto principale

4. Negoziazione della lunghezza massima dei frammenti

Senza questa estensione, TLS specifica una lunghezza massima fissa del frammento in chiaro di 2^14 byte. Può essere desiderabile per i client vincolati negoziare una lunghezza massima del frammento più piccola a causa di limitazioni di memoria o limitazioni di larghezza di banda.

Per negoziare lunghezze massime di frammento più piccole, i client POSSONO includere un'estensione di tipo "max_fragment_length" nel client hello (esteso). Il campo "extension_data" di questa estensione DEVE contenere:

enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;

il cui valore è la lunghezza massima del frammento desiderata. I valori consentiti per questo campo sono: 2^9, 2^10, 2^11 e 2^12.

I server che ricevono un client hello esteso contenente un'estensione "max_fragment_length" POSSONO accettare la lunghezza massima del frammento richiesta includendo un'estensione di tipo "max_fragment_length" nel server hello (esteso). Il campo "extension_data" di questa estensione DEVE contenere una MaxFragmentLength il cui valore è uguale alla lunghezza massima del frammento richiesta.

Se un server riceve una richiesta di negoziazione della lunghezza massima del frammento per un valore diverso dai valori consentiti, DEVE interrompere l'handshake con un avviso "illegal_parameter".

Allo stesso modo, se un client riceve una risposta di negoziazione della lunghezza massima del frammento che differisce dalla lunghezza richiesta, DEVE anche interrompere l'handshake con un avviso "illegal_parameter".

Una volta che una lunghezza massima del frammento diversa da 2^14 è stata negoziata con successo, il client e il server DEVONO immediatamente iniziare a frammentare i messaggi (inclusi i messaggi di handshake) per garantire che nessun frammento più grande della lunghezza negoziata venga inviato. Si noti che TLS richiede già che i client e i server supportino la frammentazione dei messaggi di handshake.

La lunghezza negoziata si applica per la durata della sessione, incluse le riprese di sessione.

La lunghezza negoziata limita l'input che il livello di record può elaborare senza frammentazione (cioè, il valore massimo di TLSPlaintext.length; vedere [RFC5246], Sezione 6.2.1). Si noti che l'output del livello di record può essere più grande. Ad esempio, se la lunghezza negoziata è 2^9=512, allora per le suite di cifratura attualmente definite (quelle definite in [RFC5246] e [RFC2712]), e quando viene utilizzata la compressione nulla, l'output del livello di record può essere al massimo di 805 byte: 5 byte di intestazioni, 512 byte di dati dell'applicazione, 256 byte di padding e 32 byte di MAC. Ciò significa che in questo caso, un peer del livello di record TLS che riceve un messaggio del livello di record TLS più grande di 805 byte può scartare il messaggio e inviare un avviso "record_overflow", senza decifrare il messaggio.

Alcune applicazioni potrebbero voler concordare una lunghezza massima del frammento più elevata. Ad esempio, le applicazioni di rete privata virtuale (VPN) potrebbero beneficiare dell'uso di frammenti più grandi. Si noti che per il traffico UDP (ad esempio, per DTLS), potrebbe invece essere più importante utilizzare dimensioni di frammento più piccole per evitare la frammentazione dei datagrammi UDP.

Quando la frammentazione viene utilizzata in DTLS, introduce un rischio di negazione del servizio (DoS) come descritto nella Sezione 4.1.1.1 di [RFC6347]. Un'implementazione del server dovrebbe mitigare il rischio, ad esempio non accettando un valore di 1 (2^9 byte). Un client DTLS che riceve un messaggio da un server autenticato che supera il valore negoziato DOVREBBE generare un avviso fatale di tipo "record_overflow". Tuttavia, se un client DTLS riceve un messaggio da un server non autenticato che supera il valore negoziato, il client DEVE scartare il messaggio. Il motivo delle regole diverse è che un peer autenticato può semplicemente inviare qualsiasi avviso scelga; non ha bisogno di inviare un messaggio di grandi dimensioni. Al contrario, costringere un client a rispondere a un messaggio di grandi dimensioni da un server non autenticato consente diversi attacchi.