4. Négociation de la longueur maximale des fragments

Sans cette extension, TLS spécifie une longueur maximale fixe de fragment en clair de 2^14 octets. Il peut être souhaitable pour les clients contraints de négocier une longueur maximale de fragment plus petite en raison de limitations de mémoire ou de limitations de bande passante.

Afin de négocier des longueurs maximales de fragment plus petites, les clients PEUVENT inclure une extension de type "max_fragment_length" dans le client hello (étendu). Le champ "extension_data" de cette extension DOIT contenir :

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

dont la valeur est la longueur maximale de fragment souhaitée. Les valeurs autorisées pour ce champ sont : 2^9, 2^10, 2^11 et 2^12.

Les serveurs qui reçoivent un client hello étendu contenant une extension "max_fragment_length" PEUVENT accepter la longueur maximale de fragment demandée en incluant une extension de type "max_fragment_length" dans le server hello (étendu). Le champ "extension_data" de cette extension DOIT contenir un MaxFragmentLength dont la valeur est la même que la longueur maximale de fragment demandée.

Si un serveur reçoit une demande de négociation de longueur maximale de fragment pour une valeur autre que les valeurs autorisées, il DOIT abandonner la poignée de main avec une alerte "illegal_parameter".

De même, si un client reçoit une réponse de négociation de longueur maximale de fragment qui diffère de la longueur qu'il a demandée, il DOIT également abandonner la poignée de main avec une alerte "illegal_parameter".

Une fois qu'une longueur maximale de fragment autre que 2^14 a été négociée avec succès, le client et le serveur DOIVENT immédiatement commencer à fragmenter les messages (y compris les messages de poignée de main) pour s'assurer qu'aucun fragment plus grand que la longueur négociée n'est envoyé. Notez que TLS exige déjà que les clients et les serveurs prennent en charge la fragmentation des messages de poignée de main.

La longueur négociée s'applique pour la durée de la session, y compris les reprises de session.

La longueur négociée limite l'entrée que la couche d'enregistrement peut traiter sans fragmentation (c'est-à-dire la valeur maximale de TLSPlaintext.length ; voir [RFC5246], Section 6.2.1). Notez que la sortie de la couche d'enregistrement peut être plus grande. Par exemple, si la longueur négociée est 2^9=512, alors pour les suites de chiffrement actuellement définies (celles définies dans [RFC5246] et [RFC2712]), et lorsque la compression nulle est utilisée, la sortie de la couche d'enregistrement peut être au maximum de 805 octets : 5 octets d'en-têtes, 512 octets de données d'application, 256 octets de remplissage et 32 octets de MAC. Cela signifie que dans ce cas, un pair de couche d'enregistrement TLS recevant un message de couche d'enregistrement TLS supérieur à 805 octets peut rejeter le message et envoyer une alerte "record_overflow", sans déchiffrer le message.

Certaines applications peuvent souhaiter convenir d'une longueur maximale de fragment plus élevée. Par exemple, les applications de réseau privé virtuel (VPN) peuvent bénéficier de l'utilisation de fragments plus grands. Notez que pour le trafic UDP (par exemple, pour DTLS), il peut au contraire être plus important d'utiliser des tailles de fragment plus petites pour éviter la fragmentation des datagrammes UDP.

Lorsque la fragmentation est utilisée dans DTLS, elle introduit un risque de déni de service (DoS) comme décrit dans la Section 4.1.1.1 de [RFC6347]. Une implémentation serveur devrait atténuer le risque, par exemple en n'acceptant pas une valeur de 1 (2^9 octets). Un client DTLS recevant un message d'un serveur authentifié qui dépasse la valeur négociée DEVRAIT générer une alerte fatale de type "record_overflow". Cependant, si un client DTLS reçoit un message d'un serveur non authentifié qui dépasse la valeur négociée, le client DOIT rejeter le message. La raison des règles différentes est qu'un pair authentifié peut simplement envoyer toute alerte qu'il choisit ; il n'a pas besoin d'envoyer un grand message. En revanche, forcer un client à répondre à un grand message d'un serveur non authentifié permet plusieurs attaques.