7. 安全考量

通用的 CoAP 安全考量 ([RFC7252] 第 11 节) 适用于 DoC. DoC 还继承了用于安全通信的协议的安全考量, 例如 OSCORE ([RFC8613] 第 12 节), 以及 DTLS 1.2 或更新版本 ([RFC6347] 第 5 节和 [RFC9147] 第 11 节). 此外, DoC 使用的请求模式要求维护长期存在的安全上下文. [CoAP-CORR-CLAR] 第 2.9 节就从新端点恢复这些安全上下文时可以采取的措施提供了见解.

尽管 DTLS v1.2 [RFC6347] 已被 DTLS v1.3 [RFC9147] 废止, 但在本文撰写时, 仍有许多 CoAP 实现使用 v1.2. 因此, 即使在使用 DTLS 保护 CoAP 时推荐使用更新版本, 本文档也考虑了 DTLS v1.2 的用法.

使用无保护 CoAP (见第 6 节) 时, 按第 4.2.2 节的规定将 DNS 消息的 ID 设为 0, 会使 DoC 客户端的 DNS 缓存暴露于通过响应伪造实施的缓存投毒攻击. 为缓解这种针对 DoC 的攻击, 本文档要求在 CoAP 未受保护时, 客户端的每个 DoC 查询中都必须包含不可预测的 CoAP 令牌 (见第 6 节).

对于通过 (D)TLS 或 OSCORE 进行的安全通信, 不需要使用不可预测的 ID 来防止伪造. (D)TLS 和 OSCORE 的协议设计都提供了加固机制, 用于防止注入伪造响应. 因此, 可以放心地将 DNS 消息的 ID 设为 0, 以利用 CoAP 缓存的优势.

DoC 客户端必须意识到, DoC 服务器可能以无保护方式与上游 DNS 基础设施通信, 例如使用 DNS over UDP. DoC 只能保证已交换安全上下文的通信双方之间的通信机密性和完整性. DoC 服务器可以使用另一个安全上下文与上游通信, 同时提供机密性和完整性 (例如 DNS over QUIC [RFC9250]); 但是, 虽然推荐这样做, 这在协议层面对 DoC 客户端是不透明的. 也可以在上游使用 DNSSEC [BCP237] 确保记录完整性.

DoC 客户端可能无法执行 DNSSEC 验证, 例如受限于代码大小或响应大小. 它可以信任其 DoC 服务器来执行 DNSSEC 验证; 这种信任如何表达不属于本文档范围. 例如, 可以将 DoC 客户端配置为使用特定凭据, 由此识别合格的 DoC 服务器. 该信息也可以隐含对该 DoC 服务器所执行 DNSSEC 验证的信任.