【每日文稿】2025-01-16
今日共有11篇文稿更新，涉及6个area里的8个WG
GEN
modpod
- Title: IETF Community Moderation
- Authors: Lars Eggert(lars@eggert.org), Eliot Lear(lear@lear.ch)
- Summary: 本文讨论了创建一个以IETF为界的社区管理员团队的想法。该团队将负责所有参与渠道的管理，包括邮件列表、聊天频道和其他与IETF相关的系统。为了确保公正性，IETF委员会（IETF LLC）在处理这些决定时需要咨询社区意见。此外，文稿还提供了对这一决定的一些详细信息，例如其目标、结构、流程等。最后，文稿总结了这一提议的优点和可能面临的挑战。
INT
deleg
- Title: Incrementally Deployable DNSSEC Delegation
- Authors: Philip Homburg(philip@nlnetlabs.nl), Willem Toorop(willem@nlnetlabs.nl)
- Summary: 这篇文档描述了在现有的分布式签名系统（DS）的基础上，引入新的参数来支持增量式部署和多签者架构。通过使用新增的ds和dnskeyref参数，可以简化名字服务器的管理，并允许在多签者架构下实现独立的签名和认证过程。 ds参数将多个DS记录组合成一个参数，而dnskeyref参数则指定了一个或多个DNSKEY记录。这些参数可以在递增型授权（DELEG）记录中被添加到顶级别元标签。这使得验证器无需更新已存在的DS记录即可处理新的递增授权。 此外，它还介绍了对ds和dnskeyref参数进行限制以防止未经授权的更新。当递增授权之后，验证器只能依赖于递增授权中的ds和dnskeyref参数，而不能依赖于其他类型的资源记录。 总的来说，本文提出了一个新的机制来管理递增授权，并简化了多签者架构下的操作流程。同时，也强调了需要严格控制参数的使用范围以避免潜在的安全风险。
RTG
lsvr
- Title: Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers
- Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Gaurav Dawra(gdawra.ietf@gmail.com), Jie Dong(jie.dong@huawei.com)
- Summary: 本文主要讨论了在数据中心网络中使用BGP Link-State Shortest Path Routing（BGP-SPF）协议时的一些关键因素和应用场景。首先，它概述了BGP-SPF的背景及其应用价值。其次，它介绍了BGP-SPF在数据中心网络中的部署方式，并分析了其对传统BGP协议的改进效果。最后，文稿还提到了一些BGP-SPF的应用场景，包括使用IPv6简化跨域PE、控制器能力、非集中式拓扑等。总的来说，文稿旨在为数据中心网络管理员提供简化BGP-SPF部署的方法和建议。
- Diff: 以上是关于BGP-SPF技术在数据中心网络中的应用与适用性的详细讨论。主要区别如下： 1. 强调了使用BGP作为数据中心网络的基础路由协议，简化了L3层的路由和操作。 2. 提出了BGP-SPF扩展，它允许BGP处理更复杂的L3层路由问题，如动态发现邻居、避免依赖BGP环路等，并提供了统一的接口来通告所有BGP节点、链路和前缀信息。 3. 讨论了如何部署BGP-SPF以克服现有Clos或Fat-Tree网络中存在的限制（例如，防止依赖BGP的路由反射器/控制器）。 4. 强调了BGP-SPF适用于各种网络拓扑，包括非CLOS/FAT树网络。 5. 描述了不同类型的BGP会话模型（如hop-by-hop会话），以及它们各自的优势和局限性。 6. 分析了BGP-SPF在数据中心内部或外部进行管理时的需求和挑战，提出了一种简单的BGP发现机制。 7. 提出了对安全措施的要求，但没有提供新的安全考虑。总体而言，本文总结了BGP-SPF技术在数据中心网络中的优势及其在不同网络拓扑下的适用性。
SEC
ipsecme
- Title: Group Key Management using IKEv2
- Authors: Valery Smyslov(valery@smyslov.net), Brian Weis(bew.stds@gmail.com)
- Summary: 本文提出了一种扩展到IKEv2协议（版本2）的组密钥管理（G-KM）协议，用于IPSec设备之间建立和共享密钥。该协议允许在多播组中执行组密钥管理，以实现IPSec安全协会（GSA）。 文稿首先概述了协议要求和术语，并定义了相关概念，如多播、组成员（GM）、组接收者等。然后介绍了G-IKEv2协议的组成部分，包括两个阶段：注册和重键。在注册阶段，GM通过使用GSA_AUTH交换请求加入多播组，同时获取政策和加密密钥。在重键阶段，GCKS定期更新所有GM之间的密钥，并向GM分发新的密钥。这样可以确保多播通信的安全性。 文中详细描述了G-IKEv2中的各种功能，如分配发送器标识符（SID）、验证消息、重新认证、删除密钥以及通知消息等。此外，还讨论了如何处理一些特殊情况，如数据安全性SA和密钥包传输等问题。最后，提出了对G-IKEv2的一些建议，例如采用更可靠的加密算法和提供更强大的安全性保护等。
- Diff: 该文档是关于在IPSec协议栈上实施一种组密钥管理协议（Group Key Management using IKEv2），用于提供一组IPSec设备间的安全连接以及共享密钥和政策。与之前定义的组密钥管理协议（GDOI）相比，它引入了新的机制，如多播数据安全SA、重新密钥交换等，以实现更好的安全性、效率和互操作性。它使用了IKEv2协议，并且可以在多个场景下使用，包括大中小组之间的通信。 主要区别在于： 1. 新增加了对多播数据安全SA的支持。 2. 支持多播发送者向组成员发送消息时进行重新密钥更新。 3. 取消了组密钥管理协议GDOI，并将其替换为基于IKEv2的新协议。 4. 提供了更灵活的组成员注册流程，允许GM通过多种方式注册到一个组中。 5. 增加了对重用组密钥进行重新密钥更新的能力。 6. 采用了多播模式中的多播数据安全SA来保护数据通信。 7. 集成了新的加密算法，增强了密钥传输的安全性。
- Title: Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)
- Authors: Valery Smyslov(valery@smyslov.net)
- Summary: 本文提出了在IPsec安全协议中的一个改进。文稿明确指出，当前版本的IPSec中不存在为发送方和接收方都同意不启用反重放保护的情况定义方法。此外，也没有办法通知接收方反重放保护是不可行的，比如对于多播安全关联（Multicast SA）有多个未同步发送者。 然而，现有的协议如Implicit IV在ESP中或Aggregation and Fragmentation for ESP使用协议中依赖于某些特定序列数属性。未来IPSec安全协议可能会提供更多的选项来处理反重放计数器，比如发送完整的64位序列数或完全忽略它们。这些选项需要在IKEv2中进行协商。 文稿还提出一种修改的方法：将当前版本的“Extended Sequence Numbers (ESN)”（即反重放保护序列数）改为“Sequence Numbers (SN)”，这意味着新定义的序列数用于描述IPsec包进入网络时的状态，而不是作为发送方的动作结果。新的定义更符合反重放策略的预期行为。 最后，文稿建议通过添加新的IKEv2参数表注释、修改现有参数名称以及定义新的变体ID以适应新需求。例如，将“Extended Sequence Numbers (ESN)”更名为“Sequence Numbers (SN)”。
- Diff: 该文档对IPv6地址空间中的IPv6域和子网进行了重新定义，并指出了在IPv6路由协议中如何使用这些新的概念。 1. 文档主要内容包括： - IPv6域的概念被重定义为由两个或多个IPv6链路本地地址组成的连续块，它们可以是任意长度。 - 子网的概念被重定义为由一个或多个IPv6域构成的一个逻辑区域，每个子网都有自己的IPv6域。 2. 主要区别如下： - 重定义了IPv6域和子网的概念，以适应IPv6网络的发展和需求。 - 更加清晰地描述了IPv6网络结构，有助于开发者更好地理解IPv6网络的工作原理。 - 提供了一种更灵活、可扩展的IPv6网络架构，适合未来的IPv6应用。 3. 比较了旧版和新版的主要不同点，重点强调了IPv6网络架构的变化，以及这种变化带来的好处和影响。
lamps
- Title: X.509 Certificate Extended Key Usage (EKU) for Automation
- Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), Dr. David Goltzsche(david.goltzsche@siemens.com)
- Summary: 本文主要讨论了自动化领域中的X.509证书的扩展用途。在该文档中，定义了用于工业自动化和欧洲铁路系统安全通信的特定扩展用途标识符（Extended Key Usage Key Purpose Ids）。这些标识符允许对设备进行身份验证、验证文件签名以及用于安全更新和配置文件的认证等操作。 此外，还探讨了使用这些扩展用途标识符可能带来的潜在风险，并提出了相应的策略来减少这些风险。例如，可以禁止某些组合的扩展用途标识符的使用。最终，本文强调了这些标识符的重要性，指出它们有助于识别证书的真实意图，并帮助监控网络流量以确定其目的。
- Diff: 新的文档定义了用于自动化安全通信的X.509证书扩展用途（Extended Key Usage，简称EKA），包括签名配置文件、信任锚配置文件、软件更新包和安全通信。这些证书可以用于验证工业自动化硬件或软件产品的安全性，以及安全地执行安全通信。 与旧版不同的是： 1. 定义了通用配置文件、信任锚配置文件、软件更新包和安全通信的安全通信等用途，使得工业自动化产品能够符合欧洲联盟对网络安全的要求。 2. 提供了标准的EKA IDOID，例如id-kp-configSigning、id-kp-trustAnchorConfigSigning、id-kp-updatePackageSigning和id-kp-safetyCommunication，使不同厂商的设备可以互相认证，并确保这些证书的有效性。 3. 规定了如何使用这些EKA IDOID来限制特定组合的EKA使用，以减少潜在的跨协议攻击风险。 4. 强调了在使用时应遵守的技术标准和证书政策。 总的来说，新版标准为工业自动化提供了更全面的安全保障，并明确了哪些EKA IDOID是允许使用的，从而降低了系统中的跨协议攻击风险。
oauth
- Title: Selective Disclosure for JWTs (SD-JWT)
- Authors: Daniel Fett(mail@danielfett.de), Kristina Yasuda(yasudakristina@gmail.com), Brian Campbell(bcampbell@pingidentity.com)
- Summary: 本文主要描述了Web Authorization Protocol (WAP)的一个新机制——Selective Disclosure for JWTs (SD-JWT)。它定义了一种机制，允许安全地选择性披露JSON Web Signature (JWS)中的数据元素，以满足隐私和最小化信息共享的需求。在使用这种机制时，需要确保安全性，例如避免未经授权的访问。 本文还讨论了如何将这些机制应用到具体的场景中，以及它们可能对协议栈的影响。最后，本文总结了SD-JWT的一些特点，包括它可以包含多个Disclosures、可以处理嵌套结构等，并提出了相关的概念和技术要求。
- Diff: 这个新版本的英文标准文稿定义了一个机制，允许在JSON编码数据结构作为JSON Web签名(JWS)的payload时进行选择性披露。主要区别在于： 1. 使用了"盐化哈希"的概念，即对所有需要选择性披露的数据元素，Issuer不包括这些数据的明文形式，而是使用生成器哈希值的形式来表示。 2. 提供了一种方式，通过绑定到一个密钥(如key binding)来证明持有人对该JWT的所有权，这种所有权可以被看作是通过持有私钥来控制JWT。 3. 对于具有嵌套结构的数据元素，提供了另一种格式，允许将它们包含在JWT中，并且可以提供一个用于验证的键绑定JWT。 总的来说，这一改进使得更小的信息量可以在不降低安全性的情况下进行分享，同时允许用户在满足特定需求的前提下进行定制和选择性共享。
WIT
moq
- Title: Media over QUIC - Use Cases
- Authors: Luke Curley(kixelated@gmail.com)
- Summary: 本文主要讨论了MoQ媒体传输协议在直播流传输中的应用。它涵盖了视频、音频和元数据等媒体元素的传输方式，以及如何通过订阅和重播策略实现不同的用户体验。同时，文稿也介绍了用于传递非实时和可靠直播流的使用场景。 此外，文稿还讨论了MoQ在多播会话中如何处理多个来源的广播，包括发现、参与者选择和安全考虑。最后，它概述了IANA（互联网工程任务组）的相关工作，以及对未来的考虑。总的来说，本文为开发者提供了关于如何利用MoQ传输技术来支持不同应用场景的一般指导。
- Title: Media over QUIC - Transfork
- Authors: Luke Curley(kixelated@gmail.com)
- Summary: 是基于MOQ标准的一个实验性协议，旨在解决当前实时流媒体协议中的问题。它的设计目的是提供一种通用的多对一传输方案，即使在带宽受限的情况下也能提供高质量的服务。 该文档主要讨论了MoqTransfork的基本架构、应用场景和工作流程等。它包含了消息编码规则以及实现这些规则的方法。此外，还提供了几个重要的概念，如会话（session）、轨道（track）、组（group）和帧（frame），它们共同构成了一个端到端的流媒体网络结构。 总的来说，《媒体通过QUIC传输协议》是一个为了解决现有实时流媒体协议不足而提出的解决方案。它通过简化底层协议来提高性能，并提供了一种更易于支持的应用程序接口。然而，由于缺乏统一的版本控制机制和正式的草案发布流程，该文档仍在不断发展和完善之中。
- Diff: 新的版本简化了协议设计，更注重底层协议的实现和通用性，而不再像旧版那样纠结于协议的层次化设计。关键在于引入了一种媒体层协议，允许不同节点间传递实时直播流而不依赖于具体的应用。这种协议的实现使得在低带宽环境下仍能提供高质量的实时直播体验。
IRTF
cfrg
- Title: Implementation Guidance for the PKCS #1 RSA Cryptography Specification
- Authors: Alicja Kario(hkario@redhat.com)
- Summary: 这篇文稿主要提出了对RSA加密算法进行安全改进的建议。为了保护RSA加密算法免受侧信道攻击，应遵循以下原则： 1. 所有与私钥相关的操作都必须在非常量机器指令上执行。 2. 所有使用私钥的操作都必须进行基础偏盲和指数偏盲处理。 3. 应当采用基于模运算的分步计算方法来避免泄漏信息。 此外，还提出了一种新的密钥生成方式以减少不必要的性能开销，并定义了RSA算法的安全性测试用例。针对2048位和2049位公钥大小的RSA算法进行了测试验证，证明了这些建议的有效性。文稿还讨论了一些可能的错误做法，指出这些做法可能会导致严重的安全漏洞。 总的来说，这篇文稿为实现更安全的RSA加密算法提供了指导，有助于提升RSA算法的安全性。
- Diff: 以上新版本的英文标准文稿主要提供了关于如何保护RSA加密算法免受侧向攻击的建议和方法。主要内容包括： 1. 对于RSA加密算法，需要在所有的操作中使用不依赖秘密数据的分支指令、内存访问和非常数时间机器指令。 2. 在对公钥算法进行模块化加解密时，需要确保每次计算都与秘密数据无关。如果使用简单的平方乘法算法，则会泄露部分秘密数据。 3. 应该采用蒙特利尔梯形构造来防止模块化加解密中的平方和乘法运算被泄漏的信息。这可以通过将结果分别存储在不同的内存位置来实现。 4. 应该为私有密钥执行基底混淆和指数混淆以增强对泄漏信息的防护能力。 5. 应该采取基底混淆措施来保护私有密钥，并且在模CRT实施中也应该采取类似的混淆措施。 6. 应该采取基底混淆措施来保护用于中国剩余定理优化的私有密钥。 7. 应该采取基底混淆措施来保护用于RSA加密算法的公共密钥。 8. 应该采取基底混淆措施来保护用于RSA加密算法的私有密钥。 9. 应该采取基底混淆措施来保护用于模CRT实施的公共密钥。 10. 应该采取基底混淆措施来保护用于模CRT实施的私有密钥。 11. 应该采取基底混淆措施来保护用于RSA-OAEP的填充。这应该忽略第一位填充比特并按零处理剩余位。 12. 应该采取安全API措施来避免对已知的边沿通道敏感的操作返回错误或返回无效的消息长度。 13. 对于不需要支持RSAES-PKCS-v1_5的实现，应考虑禁用这种填充模式。 14. 对于不需要支持RSAES-PKCS-v1_5的实现，应考虑实施隐式拒绝机制来隐藏失败的填充检查。 15. 有关于改进RSA加密算法的建议，但这些建议并不适用于所有情况。 总的来说，新的文档提供了更多的指导方针来帮助实现者构建更加安全的RSA加密算法。相比于旧版文档，新文档更详细地讨论了如何防御特定类型的侧向攻击，以及采用了更多元化的建议和方法。
Unknown
Unknown
- Title: Integration of DNS Domain Names into Application Environments: Motivations and Considerations
- Authors: Swapneel Sheth(ssheth@verisign.com), Andrew Kaizer(akaizer@verisign.com), Bryan Newbold(bryan@blueskyweb.xyz), N. Johnson(nick@ens.domains)
- Summary: 本文主要讨论了将域名从全球DNS整合到应用环境中的动机和考虑。文稿指出，应用环境可能希望使用全球统一、易于理解的标识符，并且可以与全球DNS实现一致的安全性、稳定性以及可扩展性。在实现这种整合时，应用程序应该考虑到以下几点： 1. 域名生命周期：应支持域名的生命周期事件，如到期、DNSSEC状态变更或技术变化等。 2. 域控验证：应实施验证机制以确保只有域名注册者或其他授权实体才能建立整合。同时，应关注域控制是否允许用户与其他域主共享该域名的控制权，以免造成混淆。 3. 完整性：应允许任何符合整合技术标准的域名被集成。 4. 同步：应为不同步的情况提供机制，但不应依赖于用户执行这些机制。 5. DNS协议演进：应意识到DNS协议可能会随着时间演变，影响其整合的有效性和安全性。 6. 标识归属：应避免假设域名是唯一持久标识符，因为域名可能被删除并重新注册或转移，导致先前注册者不再关联到域名。 7. 解析记录支持：应考虑新记录类型的支持情况，并进行适当的处理，以保证可靠访问DNS区域数据。
- Diff: 该文档是关于如何将域名从全球DNS引入到应用程序环境中的指南。主要关注的是确保这些集成能提供一致用户体验，并且在应用和全局DNS之间保持同步。文档分析了各种动机和考虑因素，包括全球一致性、通用接受性、稳定性和灵活性等。同时，还讨论了哪些技术可以用来实现这个目标，例如验证技术、完整性检查、资源能力等方面。总体来说，该文档旨在为应用程序提供一种负责任的域名集成方式，以避免混淆、碰撞和其他安全风险。