摘要

  • Oblivious CoAP 个别草案拆开两种知识：代理知道请求来自哪里却读不到内容；网关读得到内容，却不从代理收到客户端地址。
  • 草案第 7.1 节直说代理或外部攻击者容易重放加密请求。对可能改变状态的操作，接收端可用首次封装值和后续计数检查重复。

邮差不用拆信，也能把信寄两遍。28 日提交的 Oblivious CoAP 草案正面对着这个问题。它想让受限设备向服务器发送受保护的 CoAP 请求，而不让目的端知道设备身份。中转代理虽然解不开密文，却有能力把同一份密文再送一次。隐私边界成立，执行次数还得另算。

草案列出的场景包括通过 CoAP 查询 DNS、设备匿名诊断上报，以及查询资源目录。客户端用 HPKE 为网关加密原始请求，再交给普通 CoAP 转发代理。代理能看见客户端网络地址，读不到请求内容；网关解密处理请求，却不从代理得到客户端地址。两方若共享日志或共同控制，身份与内容仍可能重新拼接，所以分工本身也需要运营边界。

这种两段式安排借鉴了 Oblivious HTTP。新草案另用 CoAP 选项标记一次会话中的相关消息，让它们可以共享同一个 HPKE 上下文。它要求有愿意承接的网关，并未展示通用部署。对运营者更急迫的不是算法名称，而是密文可复制：代理或外部人即便不懂内容，也能把它重发。

草案第 7.1 节给出两条处理路。若请求方法确实安全，且服务器验证了再次处理也安全，重放可以被容忍。若请求可能改变状态，服务器可认出重复项，并在不宜重做时停止处理。首次请求可用 HPKE 封装值 enc 或它的哈希作识别标记；同一加密上下文中的后续请求，可用受完整性保护的 OCoAP count 与接收端的重放窗口比对。受保护的 Echo 选项还能增加新鲜度检查。

这里的成本落在接收端。设备可以对网关匿名，网关仍得记住已经处理过哪些密封信。草案指出了可用的识别材料，却没有给出保存多久、重启后怎么办、占多少存储的实测数据。诊断上报寄两遍可能把统计做大；会改变状态的请求寄两遍，可能让动作重复。服务器必须自己判定方法是否安全、重放记录保留多久、记录丢失后能否继续执行。

IETF Datatracker 把它列为 I-D Exists 的个别标准轨草案。真正有用的实验，不只看目的端是否认不出设备。先送一份加密请求和它的复制件，再送同一会话的后续请求；中途重启网关。记录动作执行次数、重放证据保存情况，以及哪些运营方仍能关联发送者与请求。