跳到主要内容

JEP 219：数据报传输层安全 (DTLS)

概括​

定义数据报传输层安全 (DTLS) 版本 1.0 ( RFC 4347 ) 和 1.2 ( RFC 6347 )的 API 。

非目标​

  1. 支持特定于传输的接口（例如，DTLS for ）并不是目标DatagramSocket。

  2. 支持 PMTU 发现不是目标。

成功指标​

在客户端和服务器模式下，该实现都必须与至少两个其他 DTLS 实现成功地进行互操作。

动机​

支持 DTLS 以满足越来越多的数据报兼容应用程序的安全传输要求非常重要。RFC 4347列出了 TLS 不足以满足这些类型的应用程序的多种原因：

  • “TLS 是用于保护网络流量的最广泛部署的协议。...但是，TLS 必须在可靠的传输通道（通常是 TCP）上运行。因此它不能用于保护不可靠的数据报流量。”

  • “……越来越多的应用层协议被设计为使用 UDP 传输。特别是会话启动协议 (SIP) 和电子游戏协议等协议越来越流行。”

  • “在许多情况下，保护客户端/服务器应用程序安全的最理想方法是使用 TLS；然而，对数据报语义的要求会自动禁止使用 TLS。因此，非常需要一种与数据报兼容的 TLS 变体。”

支持 DTLS 的协议包括但不限于：

  • RFC 5238，基于数据报拥塞控制协议 (DCCP) 的数据报传输层安全性 (DTLS)

  • RFC 6083，流控制传输协议 (SCTP) 的数据报传输层安全性 (DTLS)

  • RFC 5764，数据报传输层安全 (DTLS) 扩展，用于为安全实时传输协议 (SRTP) 建立密钥

  • RFC 7252，受限应用协议 (CoAP)

Google Chrome 和 Firefox 现在支持用于 Web 实时通信 (WebRTC) 的 DTLS-SRTP。 DTLS 版本 1.0 和 1.2 受到主要 TLS 供应商和实现的支持，包括 OpenSSL、GnuTLS 和 Microsoft SChannel。

描述​

我们预计 DTLS API 和实现会相当小。新的 API 应该是独立于传输的并且类似于javax.net.ssl.SSLEngine.随着工作的进展，将在此处添加有关 API 的更多详细信息。一些初步设计考虑如下：

  1. DTLS API 和实现不会管理读取超时。应用程序有责任确定适当的超时值以及何时以及如何触发超时事件。

  2. 可能会添加一个新的 API 来设置最大应用程序数据报大小（PMTU 减去 DTLS 每条记录的开销）。但是，如果未明确指定大小，则 DTLS 实现应自动调整大小。如果一个片段丢失两到三次，实现可能会减小最大应用程序数据报大小，直到它足够小。

  3. DTLS 实现应该为每个解包或包装操作消耗或生成最多一个 TLS 记录，以便该记录可以在数据报层中单独传递，或者如果传递无序，则可以更容易地重新组装。

  4. 如有必要，应用程序有责任相应地组装无序应用程序数据。 DTLS API 应提供对每个 DTLS 消息中的应用程序数据的访问。