4. 最大フラグメント長ネゴシエーション

この拡張がない場合、TLS は固定の最大平文フラグメント長として 2^14 バイトを規定しています。メモリ制限または帯域幅制限により、制約のあるクライアントがより小さな最大フラグメント長をネゴシエートすることが望ましい場合があります。

より小さな最大フラグメント長をネゴシエートするために、クライアントは（拡張された）クライアント hello にタイプ「max_fragment_length」の拡張を含めることができます (MAY)。この拡張の「extension_data」フィールドには次のものを含める必要があります (SHALL)：

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

その値は、望ましい最大フラグメント長です。このフィールドの許可される値は、2^9、2^10、2^11、および 2^12 です。

「max_fragment_length」拡張を含む拡張クライアント hello を受信するサーバーは、（拡張された）サーバー hello にタイプ「max_fragment_length」の拡張を含めることによって、要求された最大フラグメント長を受け入れることができます (MAY)。この拡張の「extension_data」フィールドには、要求された最大フラグメント長と同じ値の MaxFragmentLength を含める必要があります (SHALL)。

サーバーが許可された値以外の値に対する最大フラグメント長ネゴシエーション要求を受信した場合、「illegal_parameter」アラートでハンドシェイクを中止する必要があります (MUST)。

同様に、クライアントが要求した長さと異なる最大フラグメント長ネゴシエーション応答を受信した場合、「illegal_parameter」アラートでハンドシェイクを中止する必要があります (MUST)。

2^14 以外の最大フラグメント長が正常にネゴシエートされると、クライアントとサーバーは、ネゴシエートされた長さより大きいフラグメントが送信されないことを保証するために、すぐにメッセージ（ハンドシェイクメッセージを含む）のフラグメント化を開始する必要があります (MUST)。TLS は既に、クライアントとサーバーがハンドシェイクメッセージのフラグメント化をサポートすることを要求していることに注意してください。

ネゴシエートされた長さは、セッション再開を含むセッションの期間中適用されます。

ネゴシエートされた長さは、レコード層がフラグメント化せずに処理できる入力を制限します（つまり、TLSPlaintext.length の最大値；[RFC5246] のセクション 6.2.1 を参照）。レコード層の出力はより大きくなる可能性があることに注意してください。たとえば、ネゴシエートされた長さが 2^9=512 の場合、現在定義されている暗号スイート（[RFC5246] および [RFC2712] で定義されているもの）では、null 圧縮が使用される場合、レコード層の出力は最大 805 バイトになります：5 バイトのヘッダー、512 バイトのアプリケーションデータ、256 バイトのパディング、および 32 バイトの MAC。これは、この場合、805 バイトより大きい TLS レコード層メッセージを受信する TLS レコード層ピアが、メッセージを復号化せずにメッセージを破棄して「record_overflow」アラートを送信できることを意味します。

一部のアプリケーションは、より高い最大フラグメント長に合意することを望む場合があります。たとえば、仮想プライベートネットワーク (VPN) アプリケーションは、より大きなフラグメントを使用することで利益を得る可能性があります。UDP トラフィック（たとえば、DTLS の場合）では、UDP データグラムのフラグメント化を回避するために、より小さなフラグメントサイズを使用することがより重要になる可能性があることに注意してください。

DTLS でフラグメント化が使用される場合、[RFC6347] のセクション 4.1.1.1 で説明されているように、サービス拒否 (DoS) リスクが発生します。サーバー実装は、たとえば値 1（2^9 バイト）を受け入れないことによって、リスクを軽減すべきです。認証されたサーバーからネゴシエートされた値を超えるメッセージを受信した DTLS クライアントは、タイプ「record_overflow」の致命的アラートを生成すべきです (SHOULD)。ただし、認証されていないサーバーからネゴシエートされた値を超えるメッセージを受信した DTLS クライアントは、メッセージを破棄する必要があります (MUST)。異なるルールの理由は、認証されたピアは単に選択した任意のアラートを送信できることです。大きなメッセージを送信する必要はありません。対照的に、認証されていないサーバーからの大きなメッセージにクライアントが応答することを強制すると、いくつかの攻撃が可能になります。