RFC 7435《机会性安全：明文基线与可用时升级》中文导读
非官方中文导读声明：本页为 IETF RFC 7435《Opportunistic Security: Some Protection Most of the Time》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7435.txt。
1. 一份关于设计哲学的文档
RFC 7435 是一份信息类文档，不规定任何协议的细节，而是提出一种安全设计理念——机会性安全（Opportunistic Security，OS）。它的出发点是现实中的一个两难：
要么要求“完美安全”（强认证 + 强加密）否则就不通信，结果大量会话因对端不支持而退回完全不保护的明文；要么放弃安全，结果同样是不受保护。OS 想走中间路线。
2. 核心思想：明文为基线，可用即升级
OS 的核心很简单：把明文（既未认证也未加密）作为基线，只要连接双方都具备能力，就协商加密与认证，把会话从“零保护”提升到“有保护”。
这让“大多数时候有保护”成为现实，而不是“要么全有、要么全无”。其收益是：被动监听者即使面对海量流量，也只能看到少数未升级的明文，而无法像“全有或全无”模式那样在退化时一次性获得全部明文。
3. 已认证加密 vs 未认证加密
OS 明确区分两种保护强度，并认为二者都比明文好：
- 未认证加密（unauthenticated encryption）：仅加密，不验证对端身份。能防被动窃听，但挡不住主动中间人。机会性 TLS 大多落在这里。
- 已认证加密（authenticated encryption）：既加密又通过证书/DNSSEC/DANE 等验证了对方身份。能抗主动中间人。
OS 不要求一步到位达到已认证加密；它的策略是“先拿到加密，再逐步叠加认证”。即使只有未认证加密，也已显著优于明文。
4. 与显式安全策略的关系
一个常见误解是 OS 与“强制安全策略”冲突。规范澄清：二者并不矛盾。
显式策略（如 MTA-STS、DANE、REQUIRETLS）适用于“策略明确要求强制 TLS+认证”的对端；而 OS 填补的是策略未覆盖之处——当没有显式策略时，仍应尽力协商加密，而不是退回明文。换句话说，OS 是兜底，不是替代。
5. SMTP 机会性 TLS 作为范例
文档以 SMTP 的 STARTTLS 作为 OS 的典型示例：两跳 MTA 在 EHLO 后，若双方都通告 STARTTLS，就协商 TLS；若任一端不支持，则退回明文继续投递（因为 SMTP 的互通性优先于保密性）。
这正是“明文基线 + 可用即升级”的写照。不过文档也指出 OS 的局限：它无法抵御主动中间人对宣告的剥离（见 RFC 3207 的降级攻击），要真正抗主动攻击，必须把 OS 与 DANE/MTA-STS 等显式验证手段结合。
6. 对工程取舍的启示
对协议设计者，OS 的启示是：在定义协商机制时，默认让加密“自动发生”，把“明文”当作退化路径而非首选；同时保留“显式强制”的逃生舱（如策略文件、证书校验）以应对高安全需求。
对运维者，OS 解释了为什么你的 MTA 应当同时开启机会性 STARTTLS（覆盖大多数对端）并部署 MTA-STS/DANE（保护关键对端）——两层叠加，才是现实中可用的邮件安全姿态。
参考：https://www.rfc-editor.org/rfc/rfc7435.txt