Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8449 Mozilla
Updates: 6066 August 2018
Category: Standards Track
ISSN: 2070-1721
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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]旨在使受约束的客户机能够协商较低的记录大小。然而，“最大碎片长度”有几个设计问题（见第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.
本文件定义了“记录大小限制”扩展（第4节）。此扩展取代了本文档不支持的“最大片段长度”[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.
较小的受保护记录大小只是受限实现可能需要解决的众多问题之一。“记录大小限制”扩展只解决内存分配问题；它不解决代码大小、处理能力或带宽容量的限制。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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个八位字节的片段添加代码点，则这不会成为问题。但是，RFC6066要求服务器在接收到不理解的扩展名值时，使用“非法_参数”警报中止握手。这使得在没有连接尝试失败的风险的情况下，无法向扩展添加新值。
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”扩展，那么受约束的服务器将无法限制记录大小。
The ExtensionData of the "record_size_limit" extension is RecordSizeLimit:
“记录大小限制”扩展的扩展数据为RecordSizeLimit：
uint16 RecordSizeLimit;
uint16记录大小限制；
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值的受保护记录。未受保护的邮件不受此限制。
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中添加的内容类型和填充（即TLS 1.3的完整长度）。在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
支持所有记录大小的端点可以包括任何限制，该限制不超过协议定义的最大记录大小限制。对于TLS 1.2及更早版本，该限制为2^14个八位字节。TLS 1.3使用2^14+1个八位字节的限制。目前为协议的未来版本保留了更高的值，该版本可能允许更大的记录；除非将来的版本或扩展明确允许，否则端点发送的值不得高于协议定义的最大记录大小。服务器不得强制执行此限制；客户端可能会公布由服务器的扩展或版本启用的更高限制
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.
我不明白。如果记录大小限制扩展包含的值大于协商协议版本和扩展允许的最大记录大小，则客户端可能会使用“非法参数”警报中止握手。
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端点必须生成致命的“记录溢出”警报；接收到大于其公布限制的记录的DTLS端点可能会生成致命的“记录溢出”警报或丢弃该记录。
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.
端点应该公布“记录大小限制”扩展，即使它们不需要限制记录的大小。对于客户端，这允许服务器自行决定公布限制。对于服务器，这允许客户端知道它们的限制将得到遵守。如果未协商此扩展，端点可以发送协议或其他协商扩展允许的任何大小的记录。
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的“记录大小限制”扩展名。端点必须将收到的较小值视为致命错误，并生成“非法_参数”警报。
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发现，应单独设置。记录大小限制在握手过程中是固定的，因此应根据端点的约束而不是当前网络环境来设置。相比之下，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数据报中发送多个记录。
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.
在TLS1.2中，分组密码允许1到256个八位字节的填充。当公布的限制低于协议定义的限制时，第二个限制适用于使用分组密码的记录长度。端点不得向记录添加填充，否则会导致受保护记录超过包含最大纯文本量和最小允许填充量的受保护记录的大小。
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_和_AES_128_CBC_SHA具有16个八位字节块和20个八位字节MAC。如果记录大小限制为256，则该长度的记录至少需要11个八位字节的填充（对于[RFC5246]，MAC由加密覆盖）；或15个八位字节，如果协商了“加密然后mac”扩展[RFC7366]。有了这个限制，一个包含250个八位字节的明文的记录可以通过最多包含17个八位字节的填充，或者包含21个八位字节的“encrypt_then_mac”来填充到相同的长度。
An implementation that always adds the minimum amount of padding will always comply with this requirement.
始终添加最小填充量的实现将始终符合此要求。
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.
“记录大小限制”扩展名替换了“最大片段长度”扩展名[RFC6066]。支持“record\u size\u limit”扩展的服务器必须忽略ClientHello中出现的“max\u fragment\u length”（如果两个扩展都出现）。客户端必须将收到的“最大片段长度”和“记录大小限制”视为致命错误，并应生成“非法参数”警报。
Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length".
依赖于较小记录大小的客户端可能会继续宣传“最大片段长度”。
Very small record sizes might generate additional work for senders and receivers, limiting throughput and increasing exposure to denial of service.
非常小的记录大小可能会为发送方和接收方产生额外的工作，从而限制吞吐量并增加拒绝服务的风险。
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].
本文档在[RFC5246]中建立的“TLS ExtensionType Values”注册表中注册“record\u size\u limit”扩展名。“记录大小限制”扩展名已分配代码点28。IANA注册表[TLS-registry]将此扩展列为“推荐”（即“Y”），并指出它可能出现在TLS 1.3[TLS]中的ClientHello（CH）或EncryptedExtensions（EE）消息中。
In the same registry, the "max_fragment_length" has been changed to not recommended (i.e., "N").
在同一注册表中，“最大片段长度”已更改为“不推荐”（即“N”）。
[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，“传输层安全（TLS）协议版本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.，“传输层安全（TLS）扩展：扩展定义”，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>.
[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，“数据报传输层安全版本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，编辑，“IP版本6的路径MTU发现”，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/RFC79252016年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.Turner，“TLS和DTL的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
Email: martin.thomson@gmail.com