摘要

  • draft-ietf-tls-pake-02 始终把 PAKE 与普通 TLS 密钥交换结合；后者采用混合或后量子方案，可以保护会话流量，却未必保护经典 PAKE 消息中的长期口令。
  • 方案选择、注册记录、Finished 验证、证书身份、应用授权与口令轮换分别属于不同控制面，不能由一个“量子安全登录”标签代替。

审计报告宣布迁移完成：TLS 使用混合密钥交换，今天截获的应用密文不会在未来被量子计算机解开。

同一份抓包里还保存着经典 PAKE 的消息。十年后，它们帮助攻击者恢复了员工长期复用的口令。旧业务数据仍然保密，新的冒充却从此开始。

这不是自相矛盾，而是两个保护对象被同一个“抗量子”标签覆盖。draft-ietf-tls-pake-02 第 02 版发布于 2026 年 7 月 6 日、将于 2027 年 1 月 7 日到期，是 TLS 工作组的活跃 Informational Internet-Draft。它不是 RFC、最终注册表、实现报告或安全认证；草案还明确提醒，重要安全分析尚未完成。

低熵秘密不能直接成为 PSK

TLS 1.3 的 PSK binder 假设共享密钥具有足够熵。若直接使用人类口令，观察者可以离线检验候选。草案引入 pake 扩展，让双方运行口令认证密钥交换，把所得秘密与普通 (EC)DHE 秘密一起送入 TLS 密钥计划。

客户端仍必须发送 supported_groups 与 key_share。PAKE 不替代临时密钥交换，而是增加一个认证与密钥贡献。客户端可以列出多个不同方案，但共享同一对 client_identity 和 server_identity，降低按方案探测账户的机会。

因此，握手至少有两条密码学轨道：普通 TLS key share 负责一类机密性与前向安全属性，PAKE 负责低熵秘密知识及其注册模型。它们在密钥计划里相遇，不代表风险生命周期合并。

服务器响应不证明账户存在

服务器选出共同 PAKE 方案后，根据身份对查找注册材料。若记录不存在，它可以生成外观合理的随机响应并继续握手。客户端最终无法产生正确 Finished。

这个模拟机制阻止攻击者从 ServerHello 直接枚举账户。它也要求运营指标放弃一个习惯：不能把服务器返回 PAKE share 计作“已识别用户”。那只是服务器进入真实或模拟分支的共同外观。

模拟是否有效，还取决于包外行为。数据库访问、缓存命中、CPU 时间、错误延迟、告警类型和限速桶若不同，攻击者仍能分类。协议允许模拟，并不证明实现已经消除这些旁路。

Finished 只完成会话内的证明

客户端与服务器用 Finished 确认包含 PAKE 消息的 TLS transcript。服务器收到并验证客户端 Finished 后，才完成对客户端的认证。此前不应发送应用数据。

这条边界应进入生产门禁，而不是只写在设计文档。个性化响应、账户权限摘要甚至响应长度，都可能在 Finished 之前泄露账户存在或内容。日志必须分别保存 Finished 验证时刻与首个应用字节时刻。

Finished 成功仍不是全部结论。它证明这一 transcript 下的密钥知识，不证明开户时的现实身份、设备完整性、当前权限或业务动作完成。应用授权必须再作一次有责任主体的决定。

口令身份、SNI 与证书不在同一命名空间

草案明确指出，PAKE 的 server_identity 与 SNI 分离。前者参与注册与密码学上下文，后者通常参与路由与虚拟主机选择。若客户端同时发送 signature_algorithms，服务器选择 PAKE 后还必须发送 Certificate 与 CertificateVerify，于是又增加证书身份。

系统可以规定三者相同，但那是本地策略，不是协议自动事实。网关、多租户服务、机构级 PAKE 名称与多个 DNS 名称会让它们自然不同。

审计记录需要保存每一项的原值、验证规则和结果。把三者压成一个 authenticated_principal，会让事故调查无法区分密码知识、服务路由与证书控制。

混合 TLS 只保护它负责的秘密

普通 TLS key share 可以采用经典与后量子组合。只要组合策略满足预期，未来量子攻击者也无法从今天的记录恢复应用流量密钥。

但经典 PAKE 消息仍可能依赖椭圆曲线等未来可破的假设。周围再强的 KEM 不会重写已经发送的 PAKE transcript。若口令长期复用，未来恢复它的价值不在解密旧会话，而在冒充用户进入新会话。

这要求两个资产清单：一份列出会话密钥交换与历史流量风险；另一份列出 PAKE 方案、口令寿命、transcript 留存面和未来恢复风险。只有第一份变绿，不能关闭第二份迁移。

草案列出 OQUAKE、OQUAKE+，也描述通过外部流程使用混合 PAKE。其所依赖的后量子 PAKE 文件仍是活跃研究草案。它们可以进入试验和评估，不能被写成已完成审计的产品保证。

外部 PAKE 需要把两次交换接起来

内部 PAKE 必须在 ClientHello 与 ServerHello 两个消息内提供所需贡献。更多轮次的 PAKE 在 TLS 之前运行，输出通过 RFC 9258 导入为外部 PSK，再建立 TLS 连接。

后一次 PSK 握手成功，只证明双方持有导入后的密钥。它没有自动记录前一次交换使用了谁的身份、在哪个通道运行、是否绑定到这条连接，或是否被错误复用。

RFC 9258 要求把导入密钥绑定到协议、KDF 与上下文，并纳入产生协议的 channel binding。应用仍要正确提供这些输入。没有外部 transcript 哈希、导入身份与消费连接的最小关联收据，审计只看到链条下半段。

注册与轮换在草案范围之外

PAKE 假设双方已经拥有口令或派生验证器、身份、盐和方案参数。谁验证开户身份、谁批准重置、如何迁移方案、何时删除旧记录，草案没有规定。

握手可以严格正确，注册仍然错误。客服可能把验证器重置给冒名者；迁移可能让两个方案同时有效；账户停用可能没有撤销 PAKE 记录。

因此需要独立的注册版本号、授权来源与销毁证明。把注册数据库视为 TLS 的内部配置，会让真正的控制权隐藏在协议指标之外。

“量子安全登录”不是一个可审计状态

PAKE 改善了低熵口令进入 TLS 的方式。模拟响应改善账户枚举风险。Finished 给出 transcript 绑定的密钥确认。证书可以增加另一类服务器身份。混合 key share 可以保护历史流量。

每项都是真实能力，也都有边界。领导层若要求一个总徽章，供应方最容易挑选已经完成的部分，而把口令恢复、注册生命周期和应用授权留在注脚里。

更可靠的治理是公布分项收据：流量何时安全、口令依赖什么假设、客户端何时被认证、哪个身份被证书验证、谁授予权限、旧验证器何时失效。只有这样，“抗量子”才不会成为掩盖经典口令债务的词。

来源