ImperialViolet - 探索Kerberos式方案

Let’s Kerberos (2024年4月7日)

（我认为这个想法值得深思，但不必太过严肃——请勿恐慌。）

后量子签名的大小是否让您感到沮丧？是否对部署后量子Web PKI感到绝望？别担心！对称密码学也是后量子的！

当您连接到某个站点时，同时从DNS获取包含若干"CA"记录的记录。每条记录包含：

标识CA的UUID
ECA-key(server-CA-key, AAD=server-hostname) — 使用只有CA知道的密钥加密的服务器-CA密钥，附加认证数据为服务器主机名
密钥ID，以便CA能从上一个字段中找到"CA-key"

“CA-key"是只有CA知道的对称密钥，“server-CA-key"是服务器和CA都知道的对称密钥。

客户端找到三个UUID与其信任的CA匹配的CA记录。然后向每个CA发送包含以下内容的消息：

CA可以解密"client-CA-key”，然后使用AAD（要么是客户端指定的主机名，要么是将第一个标签替换为*以支持通配符记录的主机名）解密"server-CA-key”（来自客户端发送的DNS信息）。

CA回复Eserver-CA-key(client-server-key)，即客户端选择的密钥，使用服务器密钥加密。客户端随后可以启动与服务器的TLS连接，向其发送三个加密的客户端-服务器密钥，客户端和服务器可以使用三个共享密钥的串联来认证Kyber密钥协商。

要使此方案工作，客户端和服务器都需要与每个CA建立对称密钥。为此，它们需要建立与CA的公钥认证连接。因此这些连接将需要大型的后量子签名，但该成本可以通过客户端和服务器之间的多次连接来分摊。（服务器必须通过标准挑战以证明它们能够合法地代表给定主机名。）

一些要点：

CA能够看到客户端正在与哪些服务器通信，就像过去的OCSP服务器一样。需要技术和策略控制来防止这些信息被滥用。例如，CA至少在SEV/TDX环境中运行经过审计的代码
需要至少破坏三个CA才能实现任何攻击。虽然我们现在有证书透明度，但那是事后审计机制，在当前WebPKI中，单个CA的破坏仍然是个问题
可以要求CA发布它们为每个主机名识别的服务器密钥ID日志。它们可能选择不记录某条记录，但需要三个CA同时作恶才能破坏系统
联系CA会带来额外的延迟。然而，这可能与服务器进行Kyber交换重叠。客户端当然可以缓存和重用客户端-服务器密钥一段时间
CA可以每天生成新密钥。旧密钥可以继续工作几天。服务器每天与CA更新共享密钥。（这里非常假定使用类似ACME的自动化）
然而，各方用于建立共享密钥的公钥是非常长期的，就像现在的根证书一样
在此模型中不信任CA不必像现在这样是件大事：要求站点设置至少五个受信任的CA，这样可以在不影响的情况下不信任任何CA。即，就像不信任证书透明度日志一样
CA的撤销很容易，并且可以立即生效
CA应该是高可用的，但系统可以通过使用其他CA来处理某个CA不可用的情况。CA处理的高可用性部分设计为几乎无状态，因此应该能够很好地扩展，并且使用任播地址相当健壮

探索后量子时代的Kerberos式Web PKI革新方案