通用面试：新协议为什么应要求 TLS 1.3？

题目与使用场景

你要设计一个运行在 TCP 上的新应用层协议。产品希望首发时兼容 TLS 1.2，安全团队则希望只支持 TLS 1.3。请依据 RFC 9852 说明默认版本、握手失败行为、旧客户端迁移、后量子密码准备，以及为什么同一结论不能直接套到 DTLS。

面试官考察什么

• 是否能区分新协议要求 TLS 1.3 与既有服务迁移到 TLS 1.3 的问题边界。
• 能否解释 TLS 1.3 对弱密码、重协商、握手隐私和配置复杂度的改善，而不是只背版本号。
• 是否会把版本协商、客户端能力、可观测性、回滚和兼容成本写成可执行的发布方案。
• 是否理解 RFC 9852 明确只针对 TLS，不适用于 DTLS，并能识别 QUIC 等协议的不同集成方式。

作答前的澄清问题

先确认协议运行在 TLS 还是 DTLS、是否需要 UDP、客户端更新节奏、是否存在嵌入式设备，以及威胁模型是否包含被动窃听、降级和流量分析。再询问是否需要代理、中间设备或长期离线升级。若协议是全新设计且使用 TLS，RFC 9852 的规范性要求是起点；若是已有协议，则需要单独评估迁移和兼容窗口。

30 秒回答框架

对于使用 TLS 的全新协议，我会把 TLS 1.3 设为最低且默认版本，客户端和服务端无法达成 TLS 1.3 时终止连接。RFC 9852 允许因部署现实把 TLS 1.2 保留为额外的非默认选项，但新规范应优先 TLS 1.3。迁移方案包括能力探测、分阶段客户端升级、握手失败可诊断性和明确截止日期；PQC 采用可插拔密钥协商。这个结论不直接适用于 DTLS，因为 RFC 9852 明确说 DTLS 1.3 的部署还不够广泛。

分步骤深入解答

1. 先划清规范范围

RFC 9852 针对新协议使用 TLS 的场景，要求协议假设 TLS 1.3 可用并要求使用它。它更新 RFC 9325 的建议，但不改变 DTLS 版本要求。若协议使用 QUIC，应遵循 QUIC 自身规定的 TLS 1.3 集成，而不是把 TCP 应用层握手步骤直接复制过去。

2. 说明 TLS 1.3 的安全收益

TLS 1.3 移除了多种弱密码和复杂协商路径，并加密更多握手内容，减少隐私暴露。TLS 1.2 并非一定不安全，但需要关闭重协商、旧密钥交换和脆弱套件等额外配置；新协议强制 TLS 1.3 可以把安全基线写进协议，而不是依赖每个部署者手工拼装。

3. 定义版本协商和失败行为

协议应把 TLS 最低版本写入规范，并要求客户端至少提供 TLS 1.3。服务端选择双方支持的最高版本；若新协议只允许 TLS 1.3，则没有共同版本时必须终止连接并返回可观测的错误类别，不能静默降级到明文或 TLS 1.2。日志不能记录密钥或敏感载荷，只记录版本、错误类别和对端能力摘要。

4. 处理 TLS 1.2 的现实兼容

如果硬件或客户升级周期使 TLS 1.2 无法立即移除，可以把它定义为额外的非默认选项，明确适用版本、截止日期和风险接受人。默认配置、示例代码和测试矩阵都必须使用 TLS 1.3；TLS 1.2 路径需要单独监控、限流、禁用弱套件并提供退出开关，不能让兼容选项成为永久默认。

5. 规划客户端迁移

先统计客户端版本、库能力和失败原因，再分阶段发布：新增客户端只实现 TLS 1.3，旧客户端升级库和配置，服务端先观察协商比例，最后关闭 TLS 1.2。把握手失败映射到可行动的更新提示，准备灰度、回滚和支持流程；不要用一次性全量切换掩盖长尾设备。

6. 纳入 PQC 与运行治理

RFC 9852 指出 TLS 1.3 是后量子密码持续标准化的承载基础。协议设计应避免把密钥交换算法写死，保留升级和混合方案的扩展点。上线后监控版本分布、握手延迟、失败率、降级尝试和证书错误，定期更新密码库并通过互操作测试验证实现差异。

高质量示范回答

我会先确认这是新建的 TCP 应用层协议，而不是已有协议迁移。对使用 TLS 的新协议，我依据 RFC 9852 把 TLS 1.3 设为最低版本和默认版本；双方无法协商 TLS 1.3 就终止连接。TLS 1.2 可以因部署现实作为额外非默认选项，但规范、示例和测试必须以 TLS 1.3 为主，并写明风险、监控和关闭日期。TLS 1.3 通过移除弱密码路径、减少复杂配置和加密更多握手内容提供更一致的安全与隐私基线。迁移时统计客户端能力，先升级库和嵌入式设备，再灰度关闭 TLS 1.2；错误只暴露可行动的版本类别，不泄露密钥或载荷。密钥交换保持可扩展以便接入 PQC，并通过版本分布、失败率、握手延迟和互操作测试治理。RFC 9852 明确不适用于 DTLS，因此若协议改用 UDP，我会单独评估 DTLS 版本和部署状态。

常见错误

• 把 TLS 1.2 一律描述为不安全，忽略 RFC 9852 对新协议和既有部署的范围区分。
• 允许服务端静默降级到 TLS 1.2、明文或自定义加密。
• 把 TLS 的结论直接应用到 DTLS，或忽略 QUIC 的 TLS 集成规则。
• 只写升级客户端，没有能力盘点、失败可观测性、灰度和截止日期。
• 把密码套件写死，导致未来 PQC 或库升级无法演进。

追问及应对

为什么 TLS 1.2 只能是非默认选项？

RFC 9852 的理由是 TLS 1.3 已广泛部署，并改善了 TLS 1.2 的安全与隐私缺陷。保留 TLS 1.2 只能服务于明确的部署约束，不能让新协议的安全基线取决于各实现者是否正確关闭旧路径。

什么时候可以删除 TLS 1.2？

当客户端版本、库支持和关键地区的协商比例达到预设门槛，并完成公告、灰度和支持准备后删除。保留可观测窗口，确认失败主要来自可升级客户端，而不是未知的关键设备。

如果协议改成 UDP，是否仍然只要求 TLS 1.3？

不能直接沿用。RFC 9852 明确只针对 TLS，不针对 DTLS；UDP 方案要依据 DTLS 的实际部署、协议集成和风险单独制定版本要求。QUIC 也应遵循自身要求 TLS 1.3 的规范。