DTLS与TLS的比较

原文地址：https://www.rfc-editor.org/rfc/pdfrfc/rfc6347.txt.pdf

1. 背景简介

TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel – typically TCP [TCP]. Therefore, it cannot be used to secure unreliable datagram traffic.
TLS必须在一个可靠的传输通道上运行（如TCP），因此，无法用于不可靠的数据包传输（如UDP）。

An increasing number of application layer protocols have been designed that use UDP transport. In particular, protocols such as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable.) Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typically require a large amount of effort to design – in contrast to the relatively small amount of effort required to run the protocol over TLS.
IPsec因为一些原因（不在本文讨论范围内）只适用于某些应用，而应用层的安全协议虽然安全性较好，但设计成本非常高。

In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for
datagram semantics automatically prohibits use of TLS. This memo describes a protocol for this purpose: Datagram Transport Layer
Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to
maximize the amount of code and infrastructure reuse.
DTLS在TLS的基础上进行改造，从而适用于数据包的传输。

DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces a new version of DTLS, DTLS 1.2, which is
defined as a series of deltas to TLS 1.2 [TLS12]. There is no DTLS 1.1; that version number was skipped in order to harmonize version
numbers with TLS. This version also clarifies some confusing points in the DTLS 1.0 specification.
DTLS1.0 是基于TLS1.1改造的，DTLS1.2则基于TLS1.2。(没有DTLS1.1版本）

Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of
course), just as TLS 1.2 implementations can interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details),
with the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols do not apply.
DTLS1.2可以向下兼容DTLS1.0。

2. Usage Model

The DTLS protocol is designed to secure data between communicating applications. It is designed to run in application space, without
requiring any kernel modifications.

Datagram transport does not require or provide reliable or in-order delivery of data. The DTLS protocol preserves this property for
payload data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication
due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to
secure communication, since the DTLS protocol does not compensate for lost or re-ordered data traffic.

3. DTLS的概览

The basic design philosophy of DTLS is to construct “TLS over datagram transport”. The reason that TLS cannot be used directly in
datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle this kind of unreliability; therefore, TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal
changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new
mechanisms, we attempt to do so in such a way that preserves the style of TLS.
UDP传输中数据可能丢失，TLS没有内部机制处理这种不可靠性。因此，当数据丢失时TLS会中断连接。DTLS基于TLS做最小化的改动来解决这个问题。

Unreliability creates problems for TLS at two levels:

1. TLS does not allow independent decryption of individual records. Because the integrity check depends on the sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus will fail. (Note that prior to TLS 1.1, there was no explicit IV and so decryption would also fail.)
2. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost. The rest of this section describes the approach that DTLS uses to solve these problems.

不可靠性导致的TLS两个层面上的问题：1. TLS的完整性检查依赖消息序列号，当丢失数据后，序列号会错乱。2. TLS的握手协议假定握手消息可以被可靠传输，如果丢失握手消息则连接中断。

3.1 Loss-Insensitive Messaging

In TLS’s traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency:

1. Cryptographic context (stream cipher key stream) is retained between records.
2. Anti-replay and message reordering protection are provided by a MAC that includes a sequence number, but the sequence numbers
   are implicit in the records.
   DTLS solves the first problem by banning stream ciphers. DTLS solves the second problem by adding explicit sequence numbers.
   TLS的加密层传输中，消息间是不独立的。其中有两类依赖：1. 流式加密算法的密钥流 2. 包含消息序列号的消息认证码（MAC）
   DTLS通过禁用流式加密算法解决第1类问题，通过添加显示序列信息解决第2类问题。

3.2 Providing Reliability for Handshake

The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order; any other order is an error. Clearly, this is incompatible with reordering and message loss. In addition, TLS handshake messages are potentially
larger than any given datagram, thus creating the problem of IP fragmentation. DTLS must provide fixes for both of these problems.
TLS不允许握手消息的顺序错乱，另外，TLS握手消息可能比数据原文大，从而造成IP分片。DTLS必须解决这些问题。

3.2.1 Packet Loss

DTLS uses a simple retransmission timer to handle packet loss. The following figure demonstrates the basic concept, using the first
phase of the DTLS handshake:

Once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server. However, if the
server’s message is lost, the client knows that either the ClientHello or the HelloVerifyRequest has been lost and retransmits.
When the server receives the retransmission, it knows to retransmit.
The server also maintains a retransmission timer and retransmits when that timer expires.
DTLS握手的ClientHello消息具备超时重发机制 (包括client端和server端）

Note that timeout and retransmission do not apply to the HelloVerifyRequest, because this would require creating state on the
server. The HelloVerifyRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about
interleaving multiple HelloVerifyRequests.
注：DTLS握手的HelloVerifyRequest消息不使用超时重发，它设计的足够小，从而不会被分片。

3.2.2 Reordering

In DTLS, each handshake message is assigned a specific sequence number within that handshake. When a peer receives a handshake
message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it for future handling once all previous messages have been received.
DTLS给每一条握手消息分配一个特定的显式序列号，可以根据序列号判断握手消息的处理逻辑。

3.2.3 Message Size

TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP
datagrams are often limited to <1500 bytes if IP fragmentation is not desired. In order to compensate for this limitation, each DTLS
handshake message may be fragmented over several DTLS records, each of which is intended to fit in a single IP datagram. Each DTLS
handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possessi