RFC 8449 - Record Size Limit Extension for TLS 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8449
タイトル : RFC 8449 - TLSのレコードサイズ制限拡張
翻訳編集 : 自動生成

[要約] RFC 8449は、TLS (Transport Layer Security) プロトコルにおける「Record Size Limit Extension」に関する仕様を定めた文書です。この拡張機能の目的は、TLSを使用する通信において、送受信するレコードの最大サイズを相互に通知し合うことで、効率的なデータ転送とリソースの最適化を図ることにあります。特に、組み込みシステムやネットワークの帯域幅が限られている環境での利用が想定されています。この拡張機能は、TLS 1.2およびTLS 1.3と互換性があり、関連するRFCとしては、TLSの基本を定めたRFC 5246 (TLS 1.2) やRFC 8446 (TLS 1.3) などがあります。

Internet Engineering Task Force (IETF)                        M. Thomson
Request for Comments: 8449                                       Mozilla
Updates: 6066                                                August 2018
Category: Standards Track
ISSN: 2070-1721

Record Size Limit Extension for TLS

TLSのレコードサイズ制限拡張

Abstract

概要

An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.

トランスポート層セキュリティ（TLS）の拡張機能が定義されています。これにより、エンドポイントは、お互いが送信する保護されたレコードの最大サイズをネゴシエートできます。

This replaces the maximum fragment length extension defined in RFC 6066.

これは、RFC 6066で定義されている最大フラグメント長拡張を置き換えます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8449.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8449で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Limitations of the "max_fragment_length" Extension  . . . . .   3
   4.  The "record_size_limit" Extension . . . . . . . . . . . . . .   4
     4.1.  Record Expansion Limits . . . . . . . . . . . . . . . . .   6
   5.  Deprecating "max_fragment_length" . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction

1. はじめに

Implementing Transport Layer Security (TLS) [TLS] or Datagram TLS (DTLS) [DTLS] for constrained devices can be challenging. However, recent improvements to the design and implementation of cryptographic algorithms have made TLS accessible to some highly limited devices (see, for example, [RFC7925]).

制約のあるデバイスにトランスポート層セキュリティ（TLS）[TLS]またはデータグラムTLS（DTLS）[DTLS]を実装することは困難な場合があります。ただし、暗号化アルゴリズムの設計と実装に対する最近の改善により、一部の非常に制限されたデバイスがTLSにアクセスできるようになりました（たとえば、[RFC7925]を参照）。

Receiving large protected records can be particularly difficult for a device with limited operating memory. TLS versions 1.2 [RFC5246] and earlier permit senders to generate records 16384 octets in size, plus any expansion from compression and protection up to 2048 octets (though typically this expansion is only 16 octets). TLS 1.3 reduces the allowance for expansion to 256 octets. Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations.

保護された大きなレコードを受信することは、動作メモリが限られているデバイスでは特に困難です。 TLSバージョン1.2 [RFC5246]以前では、送信者が16384オクテットのサイズのレコードを生成できるほか、最大2048オクテットまでの圧縮と保護からの拡張が可能です（通常、この拡張は16オクテットのみです）。 TLS 1.3では、拡張の許容値が256オクテットに削減されています。暗号文に最大18Kのメモリを割り当てることは、一部の実装の容量を超えています。

An Authentication Encryption with Additional Data (AEAD) cipher (see [RFC5116]) API requires that an entire record be present to decrypt and authenticate it. Similarly, other ciphers cannot produce authenticated data until the entire record is present. Incremental processing of records exposes endpoints to the risk of forged data.

追加データを使用した認証暗号化（AEAD）暗号（[RFC5116]を参照）APIでは、それを復号化および認証するためにレコード全体が存在する必要があります。同様に、レコード全体が存在するまで、他の暗号は認証データを生成できません。レコードの増分処理により、エンドポイントは偽造データのリスクにさらされます。

The "max_fragment_length" extension [RFC6066] was designed to enable constrained clients to negotiate a lower record size. However, "max_fragment_length" suffers from several design problems (see Section 3).

「max_fragment_length」拡張[RFC6066]は、制約されたクライアントがより低いレコードサイズをネゴシエートできるように設計されました。ただし、「max_fragment_length」にはいくつかの設計上の問題があります（セクション3を参照）。

This document defines a "record_size_limit" extension (Section 4). This extension replaces "max_fragment_length" [RFC6066], which this document deprecates. This extension is valid in all versions of TLS.

このドキュメントでは、「record_size_limit」拡張機能を定義しています（セクション4）。この拡張機能は、このドキュメントで廃止された「max_fragment_length」[RFC6066]に代わるものです。この拡張機能は、TLSのすべてのバージョンで有効です。

A smaller protected record size is just one of many problems that a constrained implementation might need to address. The "record_size_limit" extension only addresses the memory allocation problem; it does not address limits of code size, processing capability, or bandwidth capacity.

保護されたレコードサイズを小さくすることは、制約のある実装で対処する必要がある多くの問題の1つにすぎません。「record_size_limit」拡張機能は、メモリ割り当ての問題のみを扱います。コードサイズ、処理能力、帯域幅容量の制限については取り上げていません。

2. Conventions and Definitions

2. 表記法と定義

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Limitations of the "max_fragment_length" Extension

3. 「max_fragment_length」拡張の制限

The "max_fragment_length" extension has several limitations that make it unsuitable for use.

「max_fragment_length」拡張には、使用に適さないようにするいくつかの制限があります。

A client that has no constraints preventing it from accepting a large record cannot use "max_fragment_length" without risking a reduction in the size of records. The maximum value that the extension permits is 2^12, much smaller than the maximum record size of 2^14 that the protocol permits.

大きなレコードを受け入れることを妨げる制約がないクライアントは、レコードのサイズが減少する危険を冒さずに "max_fragment_length"を使用できません。拡張が許可する最大値は2 ^ 12で、プロトコルが許可する最大レコードサイズの2 ^ 14よりもはるかに小さいです。

For large data transfers, small record sizes can materially affect performance. Every record incurs additional costs, both in the additional octets for record headers and for expansion due to encryption. Processing more records also adds computational overheads that can be amortized more effectively for larger record sizes. Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed.

大きなデータ転送の場合、レコードサイズが小さいとパフォーマンスに大きな影響を与える可能性があります。すべてのレコードには、レコードヘッダーの追加オクテットと暗号化による拡張の両方で追加コストが発生します。より多くのレコードを処理すると、計算上のオーバーヘッドも追加され、より大きなレコードサイズに対してより効果的に償却できます。その結果、特に拡張がほとんど必要ない場合、大きなレコードを受信できるクライアントは、拡張を提供することでパフォーマンスを低下させるリスクを嫌がります。

This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets. However, RFC 6066 requires that servers abort the handshake with an "illegal_parameter" alert if they receive the extension with a value they don't understand. This makes it impossible to add new values to the extension without the risk of failed connection attempts.

コードポイントが利用可能である場合、または2 ^ 14オクテットのフラグメントに追加できる場合、これは問題にはなりません。ただし、RFC 6066では、サーバーが理解できない値の拡張機能を受信した場合、サーバーは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。これにより、接続試行が失敗するリスクなしに、拡張に新しい値を追加することが不可能になります。

A server that negotiates "max_fragment_length" is required to echo the value selected by the client. The server cannot request a lower limit than the one the client offered. This is a significant problem if a server is more constrained than the clients it serves.

クライアントが選択した値をエコーするには、「max_fragment_length」をネゴシエートするサーバーが必要です。サーバーは、クライアントが提供した制限よりも低い制限を要求することはできません。サーバーが、サービスを提供するクライアントよりも制約を受けている場合、これは重大な問題です。

The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric. Constraints on record size are often receiver constraints.

「max_fragment_length」拡張は、クライアントとサーバーの機能が非対称である場合にも不適切です。多くの場合、レコードサイズの制約はレシーバーの制約です。

In comparison, an implementation might be able to send data incrementally. Encryption does not have the same atomicity requirement. Some ciphers can be encrypted and sent progressively. Thus, an endpoint might be willing to send records larger than the limit it advertises for records that it receives.

比較すると、実装はデータを段階的に送信できる可能性があります。暗号化には、同じ原子性の要件はありません。一部の暗号は暗号化して段階的に送信できます。したがって、エンドポイントは、受信したレコードに対してアドバタイズする制限よりも大きいレコードを送信してもかまいません。

If these disincentives are sufficient to discourage clients from deploying the "max_fragment_length" extension, then constrained servers are unable to limit record sizes.

これらの阻害要因が、クライアントが「max_fragment_length」拡張をデプロイするのを妨げるのに十分である場合、制約されたサーバーはレコードサイズを制限できません。

4. The "record_size_limit" Extension

4. 「record_size_limit」拡張

The ExtensionData of the "record_size_limit" extension is RecordSizeLimit:

「record_size_limit」拡張のExtensionDataはRecordSizeLimitです。

uint16 RecordSizeLimit;

The value of RecordSizeLimit is the maximum size of record in octets that the endpoint is willing to receive. This value is used to limit the size of records that are created when encoding application data and the protected handshake message into records.

RecordSizeLimitの値は、エンドポイントが受信できるオクテット単位のレコードの最大サイズです。この値は、アプリケーションデータと保護されたハンドシェイクメッセージをレコードにエンコードするときに作成されるレコードのサイズを制限するために使用されます。

When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. Unprotected messages are not subject to this limit.

「record_size_limit」拡張がネゴシエートされるとき、エンドポイントは、ピアから受信するRecordSizeLimit値より大きいプレーンテキストで保護されたレコードを生成してはなりません（MUST NOT）。保護されていないメッセージには、この制限は適用されません。

This value is the length of the plaintext of a protected record. The value includes the content type and padding added in TLS 1.3 (that is, the complete length of TLSInnerPlaintext). In TLS 1.2 and earlier, the limit covers all input to compression and encryption (that is, the data that ultimately produces TLSCiphertext.fragment). Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see Section 4.1).

この値は、保護されたレコードの平文の長さです。この値には、TLS 1.3で追加されたコンテンツタイプとパディング（つまり、TLSInnerPlaintextの全長）が含まれます。 TLS 1.2以前では、制限は圧縮および暗号化へのすべての入力（つまり、最終的にTLSCiphertext.fragmentを生成するデータ）をカバーします。ブロック暗号によって追加されるような、暗号化の一部として追加されるパディングは、このカウントに含まれません（セクション4.1を参照）。

An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size. For TLS 1.2 and earlier, that limit is 2^14 octets. TLS 1.3 uses a limit of 2^14+1 octets. Higher values are currently reserved for future versions of the protocol that may allow larger records; an endpoint MUST NOT send a value higher than the protocol-defined maximum record size unless explicitly allowed by such a future version or extension. A server MUST NOT enforce this restriction; a client might advertise a higher limit that is enabled by an extension or version the server does not understand. A client MAY abort the handshake with an "illegal_parameter" alert if the record_size_limit extension includes a value greater than the maximum record size permitted by the negotiated protocol version and extensions.

すべてのレコードサイズをサポートするエンドポイントには、最大レコードサイズのプロトコルで定義された制限までの制限を含めることができます。 TLS 1.2以前の場合、その制限は2 ^ 14オクテットです。 TLS 1.3は2 ^ 14 + 1オクテットの制限を使用します。より大きな値は現在、より大きなレコードを許可する可能性があるプロトコルの将来のバージョンのために予約されています。エンドポイントは、そのような将来のバージョンまたは拡張によって明示的に許可されない限り、プロトコルで定義された最大レコードサイズよりも大きい値を送信してはなりません（MUST NOT）。サーバーはこの制限を強制してはなりません。クライアントは、サーバーが理解できない拡張またはバージョンによって有効になっている上限をアドバタイズする場合があります。クライアントは、record_size_limit拡張に、ネゴシエートされたプロトコルバージョンと拡張で許可されている最大レコードサイズより大きい値が含まれている場合、「illegal_parameter」アラートでハンドシェイクを中止することができます（MAY）。

Even if a larger record size limit is provided by a peer, an endpoint MUST NOT send records larger than the protocol-defined limit, unless explicitly allowed by a future TLS version or extension.

より大きなレコードサイズの制限がピアによって提供されている場合でも、将来のTLSバージョンまたは拡張機能によって明示的に許可されていない限り、エンドポイントはプロトコルで定義された制限より大きいレコードを送信してはなりません。

The record size limit only applies to records sent toward the endpoint that advertises the limit. An endpoint can send records that are larger than the limit it advertises as its own limit. A TLS endpoint that receives a record larger than its advertised limit MUST generate a fatal "record_overflow" alert; a DTLS endpoint that receives a record larger than its advertised limit MAY either generate a fatal "record_overflow" alert or discard the record.

レコードサイズの制限は、制限をアドバタイズするエンドポイントに送信されるレコードにのみ適用されます。エンドポイントは、エンドポイントが自身の制限としてアドバタイズする制限より大きいレコードを送信できます。アドバタイズされた制限より大きいレコードを受信するTLSエンドポイントは、致命的な「record_overflow」アラートを生成する必要があります。アドバタイズされた制限よりも大きいレコードを受信するDTLSエンドポイントは、致命的な「record_overflow」アラートを生成するか、レコードを破棄する場合があります。

Endpoints SHOULD advertise the "record_size_limit" extension, even if they have no need to limit the size of records. For clients, this allows servers to advertise a limit at their discretion. For servers, this allows clients to know that their limit will be respected. If this extension is not negotiated, endpoints can send records of any size permitted by the protocol or other negotiated extensions.

エンドポイントは、レコードのサイズを制限する必要がない場合でも、「record_size_limit」拡張をアドバタイズする必要があります（SHOULD）。これにより、サーバーはクライアントの裁量で制限を通知できます。サーバーの場合、これによりクライアントは制限が守られることを知ることができます。この拡張がネゴシエートされていない場合、エンドポイントは、プロトコルまたは他のネゴシエートされた拡張で許可されている任意のサイズのレコードを送信できます。

Endpoints MUST NOT send a "record_size_limit" extension with a value smaller than 64. An endpoint MUST treat receipt of a smaller value as a fatal error and generate an "illegal_parameter" alert.

エンドポイントは、64より小さい値の「record_size_limit」拡張を送信してはなりません（MUST NOT）。エンドポイントは、より小さい値の受信を致命的なエラーとして扱い、「illegal_parameter」アラートを生成する必要があります。

In TLS 1.3, the server sends the "record_size_limit" extension in the EncryptedExtensions message.

TLS 1.3では、サーバーはEncryptedExtensionsメッセージで「record_size_limit」拡張を送信します。

During renegotiation or resumption, the record size limit is renegotiated. Records are subject to the limits that were set in the handshake that produces the keys that are used to protect those records. This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed.

再ネゴシエーションまたは再開中に、レコードサイズの制限が再ネゴシエートされます。レコードには、それらのレコードを保護するために使用されるキーを生成するハンドシェイクで設定された制限が適用されます。これは、接続が再ネゴシエートまたは再開されたときに、拡張機能がネゴシエートされない可能性があることを認めています。

The Path Maximum Transmission Unit (PMTU) in DTLS also limits the size of records. The record size limit does not affect PMTU discovery and SHOULD be set independently. The record size limit is fixed during the handshake and so should be set based on constraints at the endpoint and not based on the current network environment. In comparison, the PMTU is determined by the network path and can change dynamically over time. See [PMTU] and Section 4.1.1.1 of [DTLS] for more detail on PMTU discovery.

DTLSのパス最大転送単位（PMTU）も、レコードのサイズを制限します。レコードサイズの制限はPMTU検出に影響を与えず、個別に設定する必要があります（SHOULD）。レコードサイズの制限はハンドシェイク中に固定されるため、現在のネットワーク環境ではなく、エンドポイントでの制約に基づいて設定する必要があります。対照的に、PMTUはネットワークパスによって決定され、時間の経過とともに動的に変化する可能性があります。 PMTU検出の詳細については、[PMTU]および[DTLS]のセクション4.1.1.1を参照してください。

PMTU governs the size of UDP datagrams, which limits the size of records, but does not prevent records from being smaller. An endpoint that sends small records is still able to send multiple records in a single UDP datagram.

PMTUは、UDPデータグラムのサイズを制御します。これにより、レコードのサイズが制限されますが、レコードが小さくなるのを防ぐことはできません。小さなレコードを送信するエンドポイントでも、単一のUDPデータグラムで複数のレコードを送信できます。

4.1. Record Expansion Limits

4.1. レコード拡張制限

The size limit expressed in the "record_size_limit" extension doesn't account for expansion due to compression or record protection. It is expected that a constrained device will disable compression to avoid unpredictable increases in record size. Stream ciphers and existing AEAD ciphers don't permit variable amounts of expansion, but block ciphers do permit variable expansion.

「record_size_limit」拡張で表現されるサイズ制限は、圧縮またはレコード保護による拡張を考慮していません。制約されたデバイスは、レコードサイズの予期しない増加を避けるために圧縮を無効にすることが期待されています。ストリーム暗号および既存のAEAD暗号は可変量の拡張を許可しませんが、ブロック暗号は可変拡張を許可します。

In TLS 1.2, block ciphers allow from 1 to 256 octets of padding. When a limit lower than the protocol-defined limit is advertised, a second limit applies to the length of records that use block ciphers. An endpoint MUST NOT add padding to records that would cause the protected record to exceed the size of a protected record that contains the maximum amount of plaintext and the minimum permitted amount of padding.

TLS 1.2では、ブロック暗号は1〜256オクテットのパディングを許可します。プロトコルで定義された制限よりも低い制限がアドバタイズされると、ブロック暗号を使用するレコードの長さに2番目の制限が適用されます。エンドポイントは、保護されたレコードが最大量のプレーンテキストと最小許容量のパディングを含む保護されたレコードのサイズを超える原因となるレコードにパディングを追加してはなりません（MUST NOT）。

For example, TLS_RSA_WITH_AES_128_CBC_SHA has 16-octet blocks and a 20-octet MAC. Given a record size limit of 256, a record of that length would require a minimum of 11 octets of padding (for [RFC5246], where the MAC is covered by encryption); or 15 octets if the "encrypt_then_mac" extension [RFC7366] is negotiated. With this limit, a record with 250 octets of plaintext could be padded to the same length by including at most 17 octets of padding, or 21 octets with "encrypt_then_mac".

たとえば、TLS_RSA_WITH_AES_128_CBC_SHAには、16オクテットのブロックと20オクテットのMACがあります。レコードサイズの制限が256の場合、その長さのレコードには、少なくとも11オクテットのパディングが必要になります（[RFC5246]の場合、MACは暗号化の対象です）。「encrypt_then_mac」拡張[RFC7366]がネゴシエートされる場合は15オクテット。この制限により、最大で17オクテットのパディング、または21オクテットの「encrypt_then_mac」を含めることにより、250オクテットのプレーンテキストのレコードを同じ長さにパディングできます。

An implementation that always adds the minimum amount of padding will always comply with this requirement.

常に最小量のパディングを追加する実装は、常にこの要件に準拠します。

5. Deprecating "max_fragment_length"

5. 「max_fragment_length」の廃止

The "record_size_limit" extension replaces the "max_fragment_length" extension [RFC6066]. A server that supports the "record_size_limit" extension MUST ignore a "max_fragment_length" that appears in a ClientHello if both extensions appear. A client MUST treat receipt of both "max_fragment_length" and "record_size_limit" as a fatal error, and it SHOULD generate an "illegal_parameter" alert.

「record_size_limit」拡張は「max_fragment_length」拡張[RFC6066]を置き換えます。「record_size_limit」拡張をサポートするサーバーは、両方の拡張が表示される場合、ClientHelloに表示される「max_fragment_length」を無視する必要があります。クライアントは、「max_fragment_length」と「record_size_limit」の両方の受信を致命的なエラーとして扱わなければならず、「illegal_parameter」アラートを生成する必要があります（SHOULD）。

Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length".

小さいレコードサイズを持つことに依存しているクライアントは、「max_fragment_length」を引き続き通知する場合があります。

6. Security Considerations

6. セキュリティに関する考慮事項

Very small record sizes might generate additional work for senders and receivers, limiting throughput and increasing exposure to denial of service.

レコードサイズが非常に小さいと、送信者と受信者に追加の作業が発生し、スループットが制限され、サービス拒否の危険性が高まります。

7. IANA Considerations

7. IANAに関する考慮事項

This document registers the "record_size_limit" extension in the "TLS ExtensionType Values" registry established in [RFC5246]. The "record_size_limit" extension has been assigned a code point of 28. The IANA registry [TLS-REGISTRY] lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH) or EncryptedExtensions (EE) messages in TLS 1.3 [TLS].

このドキュメントは、[record_size_limit]拡張を[RFC5246]で確立された "TLS ExtensionType Values"レジストリに登録します。「record_size_limit」拡張には28のコードポイントが割り当てられています。IANAレジストリ[TLS-REGISTRY]は、この拡張を「推奨」（つまり「Y」）としてリストし、ClientHello（CH）またはEncryptedExtensionsに表示される可能性があることを示しています。（EE）TLS 1.3 [TLS]のメッセージ。

In the same registry, the "max_fragment_length" has been changed to not recommended (i.e., "N").

同じレジストリで、 "max_fragment_length"が非推奨（つまり、 "N"）に変更されました。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。

[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <https://www.rfc-editor.org/info/rfc7366>.

[RFC7366] Gutmann、P。、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の暗号化後MAC」、RFC 7366、DOI 10.17487 / RFC7366、2014年9月、<https：//www.rfc -editor.org/info/rfc7366>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[TLS] Rescorla、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

8.2. Informative References

8.2. 参考引用

[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[DTLS] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。

[PMTU] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[PMTU] McCann、J.、Deering、S.、Mogul、J。、およびR. Hinden、編、「Path MTU Discovery for IP version 6」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、 <https://www.rfc-editor.org/info/rfc8201>。

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.

[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。

[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.

[RFC7925] Tschofenig、H.、Ed。 T. Fossati、「モノのインターネットのためのトランスポート層セキュリティ（TLS）/データグラムトランスポート層セキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487 / RFC7925、2016年7月、<https：//www.rfc-editor。 org / info / rfc7925>。

[TLS-REGISTRY] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[TLS-REGISTRY] Salowey、J。およびS.ターナー、「TLSおよびDTLSのIANAレジストリ更新」、RFC 8447、DOI 10.17487 / RFC8447、2018年8月、<https://www.rfc-editor.org/info/ rfc8447>。

Acknowledgments

謝辞

Thomas Pornin and Hannes Tschofenig provided significant input to this document. Alan DeKok identified an issue with the interaction between record size limits and PMTU.

Thomas PorninとHannes Tschofenigは、このドキュメントに重要な情報を提供しました。 Alan DeKokは、レコードサイズの制限とPMTU間の相互作用に問題があることを確認しました。

Author's Address

著者のアドレス

Martin Thomson Mozilla

マーティン・トムソン・モジラ

   Email: martin.thomson@gmail.com