今日共有18篇文稿更新，涉及4个area里的12个WG

ART

emailcore

1. draft-ietf-emailcore-rfc5321bis-36

  • Title: Simple Mail Transfer Protocol
  • Authors: Dr. John C. Klensin(john-ietf@jck.com)
  • Summary: 本文主要介绍了简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)的基本功能和结构。它澄清了先前相关文档中的许多细节，包括关于使用SMTP进行电子邮箱传送和其他用途的信息。本文还讨论了扩展机制、错误代码、以及安全考虑等重要方面。本文是基于最新的RFC 5321标准更新的一个版本。
  • Diff: 新的文档（SMTPO）规范了互联网电子邮件传输的基本协议。与之前RFC 5321等旧版标准不同的是，它对一些核心概念进行了更新和澄清，比如明确了SMTP的用途，并将一些历史上的变化合并到一起以减少错误风险。 关键区别包括： 1. 新版本增加了对于使用SMTP作为邮件发送工具的讨论，而之前没有这一部分。 2. 对于一些旧版标准中的不适用内容进行了删减或替换。 3. 将SMTP扩展机制纳入到了当前的文档中，以及补充了一些相关的信息。 4. 确定了IANA注册表的相关信息，使之更加符合现代实践和思考。 5. 支持了向更先进的电子邮件协议如RFC 6409进行过渡。 6. 提供了一个概述性文件，列出了所有已变更的条目，以便审查和投票。

sipcore

1. draft-mongrain-sipcore-siprec-fix-mediatype-00

  • Title: Updates to SIPREC correcting Metadata Media Type
  • Authors: Dan Mongrain(dan.mongrain@motorolasolutions.com)
  • Summary: 本文为 RFC 7866 的更新文档，纠正了 RFC 7865 和 RFC 7866 中关于记录元数据标签不一致的问题，并指出了新的媒体类型。此外，还对 IANA 注册进行了说明和更新。该文档提供了统一的标识方法，以确保记录元数据在 SIP 应用程序中的正确使用。

OPS

v6ops

1. draft-cao-v6ops-ipv6-monitoring-deployment-01

  • Title: IPv6 Network Monitoring Deployment Analysis
  • Authors: Chang Cao(caoc15@chinaunicom.cn), Jing Zhao(zhaoj501@chinaunicom.cn), Mingshuang Jin(jinmingshuang@huawei.com), Ran Pang(pangran@chinaunicom.cn)
  • Summary: 是一份探讨当前对IPv6网络部署进行监控的方式，以及提出新的要求以推进IPv6部署进一步发展。文稿首先概述了IPv6网络部署的趋势和挑战，并分析了现有监测方法面临的局限性。然后提出了改进需求，包括更细致的数据收集和全面的数据分析。最后总结指出，应通过技术研究和标准制定来优化和标准化监控方法、整合分析方法、接口模型等。此外，还讨论了安全考虑和IANA建议。 总的来说，该文档为促进IPv6网络的发展提供了重要的指导和参考。
  • Diff: 这篇新的英文标准文稿对当前的IPv6部署监控方法进行了深入剖析，并提出了改进的方向和要求。主要内容包括： 1. 目前的IPv6部署监控方法存在几个问题：一是监测覆盖范围受限于地区或特定网络；二是深度不足，特别是在边缘节点的关注度较低；三是视角局限在网络安全方面；四是缺乏集成的分析方法和技术模型。 2. 文稿提出需要解决这些问题，建议加强数据收集、全面数据分析以及开发一个综合平台来展示可视化数据。同时，还提出了对于IPv6支持状态进行优化的需求。 与旧版的英文标准文稿相比，该新版增加了更多的专业术语和行业背景信息，同时也更详细地讨论了IPv6部署面临的挑战和障碍。此外，新版也更加强调了数据集成的重要性，并提出了未来可能的技术发展方向。总的来说，新版文稿比旧版更为系统、全面且有针对性。

RTG

idr

1. draft-wang-idr-next-next-hop-nodes-02

  • Title: BGP Next-next Hop Nodes
  • Authors: Kevin Wang(kfwang@juniper.net), Jeffrey Haas(jhaas@pfrc.org), Changwang Lin(linchangwang.04414@h3c.com), Jeff Tantsura(jefftant.ietf@gmail.com)
  • Summary: 本文讨论了在BGP协议中引入一个新的特性——Next-next Hop Nodes（NNHN），用于描述一个路由到下一个节点的下一跳节点，同时提供了一个新的编码格式。这个特性允许BGP路由器学习和使用多个下一跳节点来优化转发决策。此外，还提到了如何处理错误情况和安全考虑，以及IANA注册号。总的来说，该文档提供了将下一跳节点信息添加到BGP路由中的方法，并定义了如何正确使用这种新特性的操作指南。
  • Diff: 本文提出了一种新的能力——Next-next Hop Nodes（NNHN）能力，它允许BGP路由器发送下一个-下一个跳节点的列表，以便进行负载均衡和优化路由选择。 与旧版相比，新版在需求语言部分没有改动，而是引入了新的特性代码2（NHC），并在编码方式、发送和接收流程等方面进行了修改。此外，新版还增加了操作考虑和安全性要求，并对IANA考虑进行了更新。总体来说，新版更加规范和详细地定义了NNHN能力的概念和实现细节。

mpls

1. draft-ietf-mpls-mna-fwk-14

  • Title: MPLS Network Actions (MNA) Framework
  • Authors: Loa Andersson(loa@pi.nu), Stewart Bryant(stewart.bryant@gmail.com), Matthew Bocci(matthew.bocci@nokia.com), Tony Li(tony.li@tony.li)
  • Summary: 本文主要探讨了MPLS网络动作(MNA)框架的概念和结构。MNA是用于标识影响分组转发或处理信息（如监测）的MPLS标签栈中操作的一种技术，以及用于转移附加数据以支持这些操作的能力。 MNA架构为开发通用的网络动作能力和能力提供了基础，从而可以支持不同类型的网络行为。MNA技术还可以定义新的标签、流量分类(TC)和时延(TTL)字段的新含义，同时保留旧的含义，使其与现有功能相容。 本文概述了MNA框架的基本概念，并描述了其在标准中的规范性定义。此外，它还讨论了MNA解决方案可能需要考虑的一些管理问题，包括如何同步使用标签来表示开始MNA子栈的行为。最后，它强调了安全性考虑，指出在引入任何端到端安全机制的情况下，可能会有额外的安全漏洞需要解决。 总的来说，本文提供了一个清晰的框架，指导MNA方案的设计和实现，以满足各种需求，确保MPLS网络的稳定性并提高其安全性。
  • Diff: 本文提供了关于MPLS网络动作(MNA)技术的架构框架，用于指示对标签交换路径（LSP）和/或MPLS分组进行的影响转发或其他处理的操作以及传输为这些操作需要的数据。MNA解决方案从这个框架中发展而来，旨在满足RFC9613中发现的要求。此外，MNA可能支持与其他现有功能重叠的功能。MNA允许在LSP中的特定位置进行深度编码，并且可以更深入地编码NAS和后栈数据。 相比于旧版本，本文的主要区别在于： 1. 引入了新的术语，如“扩展特殊目的标签”、“可选扩展标识符”等。 2. 提供了一个更加通用的定义语言，包括规范性定义、注释性的定义和缩写。 3. 增加了对可选项的考虑，比如是否使用用户自定义标签。 4. 强调了MNA的结构化设计，以确保具有相同行为的MNA包的正确顺序执行。 5. 增加了对不同情况下的处理选择的支持。 总之，本文扩大了MNA的技术范围，提供了一种更加结构化的解决方案，使未来的MNA技术开发更加容易。

SEC

acme

1. draft-ietf-acme-onion-05

  • Title: Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names
  • Authors: Q Misell(q@as207960.net)
  • Summary: 是关于自动证书管理环境（ACME）的扩展，用于允许在Tor隐藏服务上自动签发证书。本文讨论了如何验证“.onion”专用用途域名的控制，并提供了新的“onion-csr-01”挑战来支持这一目的。此外，还定义了与隐藏服务相关的认证权威授权（CAA）资源记录集和相应的错误类型。 总结如下： 1. 提出了验证“.onion”专用用途域名控制的方法。 2. 定义了新的“onion-csr-01”挑战以支持自动签发证书。 3. 列举了相关标准文档参考文献，如ACME、RFC系列等。 4. 强调了使用“dns”标识符类型的安全性问题和对特定应用场景的关注，如退出劫持、安全访问等。 总的来说，《ACME for .onion》提供了一套完善的安全机制，为在Tor网络上的隐藏服务提供证书签发服务。
  • Diff: 以上新版本的英文标准文稿详细介绍了ACME对于特殊用途域名(".onion")的证书管理环境扩展方案，包括： 1. 定义了新的验证挑战类型"onion-csr-01"，用于验证".onion"特殊用途域名。 2. 新增了相关的资源记录集，如CAA、onionCAA等，并规定了其处理流程和要求。 3. 增加了ACME客户端向隐藏服务发送CSR时使用的额外字段，用于证明控制该域名。 4. 在ACME服务器和隐藏服务之间增加了交互环节，允许隐服务使用CCA政策。 5. 对于不支持在ACME服务器处获取隐藏服务第二层描述信息的ACME服务器，提供了替代性的方法。 总体来说，与旧版标准文稿相比，本文档的主要区别在于引入了针对".onion"特殊用途域名的新验证方式，对相关资源记录集进行了更新，简化了ACME客户端与隐藏服务之间的交互流程，并添加了CCA认证机制。这些改进使得ACME协议能够更加灵活地满足".onion"特殊用途域名的管理需求。

cose

1. draft-reddy-cose-jose-pqc-hybrid-hpke-04

  • Title: PQ/T Hybrid KEM: HPKE with JOSE/COSE
  • Authors: Tirumaleswar Reddy.K(kondtir@gmail.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net)
  • Summary: 本文主要阐述了混合公钥加密（HPKE）与JSON Web Key Elliptic Curves（JOSE）和COSE相结合的一种新的安全协议——混合公钥封装机制（PQ/T Hybrid KEM）。该协议利用传统和量子计算安全的两种算法，为用户提供了一种既可抵抗传统攻击又具有抗量子攻击能力的安全性。该协议通过定义新的HPKE---格式来注册多个Ciphersuite组合，并提出了一个用于保护共享秘密的联合算法，以确保至少有一个组件算法是安全的。 此外，还讨论了关于使用此新协议的一些重要概念和技术细节，包括安全性考虑、认证套件注册以及可能的变更控制等。最后，介绍了需要遵循的一些规则和建议，如验证和分析算法、实施要求等。总之，本文旨在提供一种混合公钥加密协议的新方法，以提高数据传输的安全性和完整性。
  • Diff: 本文介绍了关于混合公钥加密（HPKE）和量子计算安全性的结合的新标准文档，即PQ/T Hybrid KEM：基于HPKE的联合使用传统和量子算法。主要内容包括： 1. 对于该文档的摘要进行了删除。 2. 文档提供了介绍、定义等通用部分，以及关于构造的详细说明。 3. 定义了PQ/T Hybrid KEM的概念，指出它是两种不同类型的算法组合在一起的一种机制。 4. 指出了HPKE作为其基础的一部分，并解释了它如何与JOSE和COSE进行集成。 5. 提供了对用于注册多个PQ/T Hybrid KEM的ciphersuite信息，这些cipher suites支持HPKE协议中的两种算法。 6. 还提到了一些安全性考虑，比如共享秘密的实现方式应确保即使有一个或多个算法不可用也能保证安全。 7. 描述了IANA（国际互联网地址分配机构）在某些情况下可能会添加新的值到相关资源集的信息。 总的来说，新版本文档更注重概念性描述和整体架构的搭建，而没有过多地深入阐述具体的实施细节和实际应用案例。

kitten

1. draft-ietf-kitten-scram-2fa-05

  • Title: Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
  • Authors: Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 本文主要介绍了一种名为SCRAM的扩展，用于增强密码认证。它提供了一个简单的机制来支持双因素身份验证（2FA）。本文还讨论了如何使用时间戳和其他第二因子，如FIDO U2F和TOUP。 文稿总结指出，SCRAM可以与其他认证协议一起使用，并且可以提供额外的安全性。例如，它可以与XMPP一起工作，以实现基于密码的2FA。此外，SCRAM还可以用于快速重置用户凭据，而无需进行2FA认证。这些功能使得SCRAM成为一种实用的身份验证工具。然而，尽管SCRAM提供了强大的安全特性，但它仍然需要用户输入才能完成其基本功能，因此仍存在一些改进空间。 总的来说，SCRAM是一个很有前景的身份验证机制，具有广泛的应用前景。
  • Diff: 上述新版本的英文标准文稿主要对现有的简单认证和安全层（SASL）机制盐化挑战响应（SCRAM）进行了扩展，以支持二因素身份验证（2FA）。与旧版相比，主要区别如下： 1. 更多的第二因子类型：增加了“totp”和“ctap1”两种类型的第二因子。 2. 更详细的语法描述：对新的SCRAM属性进行了详细定义，包括类型、值等，使得实现更加明确。 3. 指定的额外参数：在一些情况下，如使用TOTP时，需要指定类型和值，而在使用FIDO CTAP1/U2F时，则需指定类型、挑战和值。这些额外参数的设置，使得实施更灵活。 4. 新的示例代码：提供了几个示例，用于展示如何将TOTP和FIDO CTAP1/U2F与其他现有机制组合使用。 5. 安全性考虑：强调了使用TOTP或FIDO CTAP1/U2F进行2FA时的安全问题，并提出了相应的解决方案。 总的来说，这一更新加强了SCRAM的可扩展性和灵活性，同时提高了安全性要求，为2FA提供了一种更为有效的支持方式。

lamps

1. draft-ietf-lamps-x509-shbs-12

  • Title: Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure
  • Authors: Daniel Van Geest(daniel.vangeest@cryptonext-security.com), Kaveh Bashiri(kaveh.bashiri.ietf@gmail.com), Scott Fluhrer(sfluhrer@cisco.com), Stefan-Lukas Gazdag(ietf@gazdag.de), Stavros Kousidis(kousidis.ietf@gmail.com)
  • Summary: 本文讨论了使用状态全量哈希签名(HSS)、扩展梅克尔树验证(MMST)和扩展梅克尔树多分支验证(MMST^MT)进行数字签名的安全性问题。这些方案可以防止量子计算机攻击，但它们在签发证书时不能生成无限数量的签名，因此不适合交互协议。 总的来说，文档提出了以下几点建议： 1. 使用安全的密钥管理策略，如记录未使用的签名并跟踪每个产生的签名。 2. 采用适当的备份恢复策略来确保在发生技术困难时能够保持签名的可用性。 3. 应该限制对私钥的访问，并实施有效的状态管理以避免重用签名。 然而，尽管这些措施可以帮助保护私钥不被滥用，但在大多数情况下，将私钥用于较少的签名仍然更合适。此外，由于HSS和XMSS私钥只能产生有限数量的签名，一些使用特定场景可能会考虑在私钥的生命周期内只签署有限数量的签名。
  • Diff: 上述新版本的英文标准文稿主要在以下方面进行了重大改进和扩展： 1. 定义了新的状态化哈希签名（HBS）算法标识符、参数和公共密钥。 2. 预定义了用于标识不同状态化哈希签名算法的新对象ID。 3. 对于使用状态化哈希签名的证书，规定了至少包含数字签名、非否认性、关键认证签名和撤销列表等特定属性。 4. 提供了关于如何正确管理状态化的哈希签名私钥的信息。 5. 描述了如何防止状态化哈希签名私钥被滥用的方法。 6. 提出了备份和恢复策略，以保证状态化哈希签名证书的安全性。 7. 引入了一个用于标识SMI安全为PKIX模块标识符的新对象ID。 总的来说，新版文档更加详尽地介绍了状态化哈希签名的实现细节，并提供了详细的指南来确保其安全性。同时，也增加了对状态化哈希签名私钥管理和备份恢复机制的讨论。这些改进使得该文档成为了一种重要的参考资源，对于理解状态化哈希签名的原理和实施方法具有重要意义。

oauth

1. draft-ietf-oauth-sd-jwt-vc-07

  • Title: SD-JWT-based Verifiable Credentials (SD-JWT VC)
  • Authors: Oliver Terbu(oliver.terbu@mattr.global), Daniel Fett(mail@danielfett.de), Brian Campbell(bcampbell@pingidentity.com)
  • Summary: 本文讨论了如何使用JSON Web Tokens (JWT)表示Verifiable Credentials（验证凭据），以及这些凭据的安全性。其中，提出了一种称为Selective Disclosure JWT (SD-JWT)的格式，用于在JWT中进行选择性披露。此外，还定义了一个名为Type Metadata的数据结构，用于描述凭据的类型和显示方式。 文稿主要分为以下几部分： 1. 引言：概述了Issuer-Holder-Verifier模型、SD-JWT作为凭据格式的用途，以及安全性考虑。 2. 资源声明：详细解释了基于SD-JWT的凭证资源声明的格式及其内容。 3. JWT凭据中的类型标识符（vct）：定义了凭证类型标识符的格式和含义。 4. 展示数据：说明了如何在凭证上附加展示信息。 5. 数据完整性：提供了关于数据完整性的概念性和实践性的定义。 6. 显示元数据：对凭据进行了标记，并提供了一些关于其如何显示的信息。 7. 安全性考虑：讨论了服务器端请求伪造、生态系统的公钥验证方法等安全问题。 8. 显式元数据：对凭据进行编码并附加了一些元数据以使其更具可读性。 9. 媒体类型和数据格式：介绍了媒体类型和JSON Web Token的Claims等数据格式的相关规范。 总的来说，本文探讨了如何将JSON Web Token与Verifiable Credentials相结合，同时确保凭证的安全性。它为开发者提供了实现基于JSON Web Token的验证凭据的工具。
  • Diff: 以上新版本的英文标准文稿主要在以下方面进行了更新和改进： 1. 更正了媒体类型定义：将原来的vc+sd-jwt更改为dc+sd-jwt，以避免与W3C的Verifiable Credentials Data Model冲突。 2. 将新的JWT CLAIM vct（可验证凭证类型）定义为一种碰撞-抵抗名称，并明确其作用。 3. 在认证规则中添加了对密钥绑定的要求，如使用确认方法来证明持有者的身份等。 4. 对证书解析过程进行了补充说明。 5. 对文档历史记录进行了整理。 6. 提供了更多示例。 总的来说，主要是对JWT格式进行了优化，增加了安全性要求，扩展了数据结构，并提供了一些实用的示例。

scim

1. draft-ietf-scim-events-07

  • Title: SCIM Profile for Security Event Tokens
  • Authors: Phillip Hunt(phil.hunt@independentid.com), Nancy Cam-Winget(ncamwing@cisco.com), Mike Kiser(mike.kiser@sailpoint.com), Jen Schreiber(jennifer.winer@workday.com)
  • Summary: 本文定义了用于SCIM服务提供商和接收者的安全事件(Security Events)。这些事件描述了某个状态变化的发生，可以用来触发接收者定期监控一段时间内发生的变化。例如，当一个用户在域间被添加了一个新角色时，这个用户的资源就会被加入到新的事件流中。此外，还有使用HTTP预设：异步响应来请求异步响应的例子。本文还定义了一些通用的安全事件属性，并详细介绍了不同类型的事件。 总结如下： 本文定义了用于SCIM服务提供商和接收者的安全事件（Security Events）。这些事件描述了某个状态变化的发生，可以用来触发接收者定期监控一段时间内发生的变化。例如，当一个用户在域间被添加了一个新角色时，这个用户的资源就会被加入到新的事件流中。此外，还有使用HTTP预设：异步响应来请求异步响应的例子。本文还定义了一些通用的安全事件属性，并详细介绍了不同类型的事件。
  • Diff: 新的(SCIM)规范定义了用于SCIM服务提供商和接收者之间的安全事件信号(Security Event Token),通过这些事件可以实现对状态变化的同步查询、资源复制以及协调等场景。 与旧版相比，主要有以下区别： 1. 新版使用了新的URI前缀（urn:ietf:params:SCIM:event）来标识SCIM事件，有助于区分不同的事件类型。 2. 改进了SCIM客户端发送请求时使用HTTP头部“Prefer: Async-response”（即“希望：异步响应”）的机制，允许SCIM协议客户端在必要时发出异步响应请求。 3. 增加了SCIM事件发布者和服务提供者的配置管理，例如支持SCIM异步事务注册等。 4. 引入了新的隐私和安全性考虑。 5. 标准化了一些特定于SCIM的服务端点，如SCIM异步事务头注册等。 总的来说，新版SCIM规范增加了更多的功能特性，以更好地满足不同场景下的需求，同时提高了系统的可扩展性和灵活性。

sshm

1. draft-ietf-sshm-ssh-agent-01

  • Title: SSH Agent Protocol
  • Authors: Damien Miller(djm@djm.net.au)
  • Summary: 本文主要讨论了使用SSH协议进行远程连接和登录时, 客户端如何与代理服务器交互以请求和执行私钥操作。该文档描述了代理服务器协议的通用结构、消息格式以及其扩展机制。它还介绍了SSH协议中的公共密钥编码方式以及如何删除或添加代理服务器上的键等。最后, 文档详细阐述了安全措施, 如防止攻击者访问代理服务器及其存储的密钥。 总的来说, 本文提供了一个详细的SSH协议代理服务器协议的定义和实现指南, 对于熟悉SSH协议的开发者来说具有很高的参考价值。
  • Diff: 本文档为一篇新的英文标准文档，主要对现有的SSH协议中的代理（Agent）部分进行了详细描述。 与旧版相比，本文的主要区别在于： 1. 简化了现有协议的表述方式，使之更加清晰、易于理解。 2. 引入了新的约束和扩展机制，使得协议更灵活，能够支持更多的功能。 3. 对代理的功能和行为进行了详细的定义，使其符合现代安全需求。 4. 提供了一个标准化的接口来请求代理服务，使客户端可以方便地获取和管理代理信息和服务。 总的来说，新版文档比旧版在规范性、灵活性以及可操作性方面有了显著提升，有助于推动SSH协议的安全性和可靠性发展。

Unknown

Unknown

1. draft-melnikov-sasl2-02

  • Title: Extensible Simple Authentication and Security Layer (SASL)
  • Authors: Dave Cridland(dave@cridland.net), Thilo Molitor(thilo@eightysoft.de), Matthew Wild(mwild1@gmail.com), Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 本文主要讨论了SASL协议，它是一种提供在连接型协议中的身份验证和数据安全服务的框架。SASL定义了一个结构化的接口来连接协议与机制之间，从而允许新的协议重用现有机制，并允许老的协议使用新机制。此外，它还定义了一种协议用于在数据安全层上进行后续协议交换。本文提出了一些改进措施，以解决当前版本中发现的一些问题。 本文的重点在于扩展SASL的能力，以支持更多的功能，如两步验证（2FA）或强制密码更改等任务。这些任务可以被视为SASL机制的一个子集，但它们并不尝试建立新的授权标识，也不需要建立新的安全性层。 此外，本文还讨论了SASL协议如何工作以及服务器如何请求额外的任务完成。服务器会发送一个继续要求的消息，指示客户端可能还需要执行其他任务。这种模式类似于SASL机制本身。 最后，本文还讨论了SASL的安全性考虑，并提出了相关的建议。例如，它可能会包括对2FA或其他任务的支持，以及对共享密钥生成和重新认证令牌生成的支持。 总的来说，本文提供了有关SASL协议的新见解，特别是关于如何扩展其能力以支持更多功能的方法。此外，它也提出了相关的安全性考虑和建议。
  • Diff: 本文是关于扩展简单认证和安全层（SASL）框架的一份标准文档。与旧版相比，它增加了以下主要内容： 1. 详细描述了如何结构化SASL机制，以及如何在协议中包括支持SASL的功能。 2. 增加了对额外协议要求的规定，如支持二因素认证（2FA）或多因素认证（MFA），强制性密码更改等任务的要求。 3. 描述了如何在连接上下文中提供数据安全性服务，并定义了通过连接携带数据安全性层的方法。 4. 提供了一种服务器请求执行额外身份验证相关任务的方式，例如需要进行第二步认证和/或需要更改密码的任务。 5. 对服务器来说，如何指示如果成功完成了一个额外的任务，是否还需要执行其他任务。 6. 增加了对SASL机制共享密钥生成后成功的必要性实现的说明。 7. 示例显示了如何为满足这些要求的附加任务创建新的协议。 8. 安全考虑提供了针对扩展SASL的建议，但没有列出具体的安全措施。 总体来看，本文旨在进一步完善SASL框架，以更好地支持网络应用中的安全性和可扩展性需求。


2. draft-bortzmeyer-more-edes-01

  • Title: Addition of Extended DNS Errors codes
  • Authors: Stéphane Bortzmeyer(bortzmeyer+ietf@nic.fr)
  • Summary: 本文为ICANN(Internet Corporation for Assigned Names and Numbers)提交的一个标准文档，其中对现有的EDE（Extended DNS Errors）进行了扩展，新增了三个新的EDE：一个是说响应被定制化以客户端IP地址为基础；另一个是说响应被设计为最小化的；最后一个是对本地根的响应。这三个新代码可以通过EDNS协议发送，并且在发送给客户端时需要复制。另外，这个文档还提出了一个请求，将这些新的EDE分配到IANA(IANA)注册表中，并添加到“Extended DNS Error Codes”类别中。 总的来说，这个文档主要介绍了如何通过EDNS协议向客户端提供更详细或更具针对性的信息，以及如何根据客户端IP地址进行定制化和最小化回答，同时也提出了对于使用这些EDE的安全性和可靠性要求。此外，还提出了一项请求，让IANA将这些新的EDE添加到其注册表中，并作为文档的一部分发布出来。
  • Diff: 以上是针对DNS扩展错误代码的新版本文档。 该文档新增了三种新的EDE（Extended DNS Errors）：一种表示响应被定制以使用EDNS（EDNS客户端子网，[RFC7871]），另一种表示响应故意最小化，第三种表示来自本地根。 对于EDE的定义和用途进行了详细的说明，并对它们的分配、安全考虑等做了相应的描述。在IANA注册码方面，提出了请求并建议将其添加到“Extended DNS Error Codes”中，但没有详细列出具体编码信息。 总的来说，这个新版本的主要区别在于增加了更多关于EDE的定义、用途以及其分配等方面的信息。同时，在安全性方面也给出了更具体的指导，强调了在使用这些错误代码时需要谨慎对待。


3. draft-melnikov-scram-bis-05

  • Title: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
  • Authors: Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 本文更新了SCRAM（Salted Challenge Response Authentication Mechanism）和SASL（Simple Authentication and Security Layer）机制的相关实施指南，以适应更现代的安全实践。文中提到，在使用TLS 1.3或更高版本时，应采用“tls-exporter”频道绑定作为默认绑定方式；并且推荐使用SCRAM-SHA-512、SCRAM-SHA3-512等替代SCRAM-SHA-1-PLUS和SCRAM-SHA1，以提高安全性。 此外，还指出了SCRAM机制的安全性考虑点，如在使用过程中需要确保使用TLS通道已协商会话哈希扩展或者避免使用会话恢复；以及建议使用强安全机制，如SHA-512，来提高SCRAM机制的安全性。 总的来说，本文为实现基于SCRAM和SASL机制提供了详细的实施指南，并提出了相应的安全性和性能要求，有助于提高系统的安全性。
  • Diff: 这篇新的英语标准文档是对盐浴挑战响应认证机制（SCRAM）SASL和GSS-API机制实施指南的更新。主要内容包括： 1. 更新了基于现代安全实践的SCRAM简单认证和安全性层（SASL）机制的实施要求。 2. 对SCRAM机制使用的通道绑定条件进行了澄清，指出在使用SCRAM时应使用"tls-unique"或"tls-exporter"作为默认的通道绑定。 3. 描述了如何将SCRAM哈希存储在LDAP目录中，该格式兼容所有版本的SCRAM描述符，包括SCRAM-SHA-256、SCRAM-SHA-512和SCRAM-SHA3-512等。 4. 提出了对IANA进行了一些修订，增加了有关SCRAM-SHA-1、SCRAM-SHA-1-PLUS、SCRAM-SHA-256和SCRAM-SHA-256-PLUS等机制的额外参考文件。 与旧版相比，本文的主要区别在于引入了更先进的安全实践，并更新了关于SCRAM机制的实施建议。此外，还扩展了支持两因素身份验证的特性以及用于解决移动设备性能问题的方法。


4. draft-melnikov-scram-sha3-512-05

  • Title: SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
  • Authors: Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 该文档注册了两个新的SASL机制：SCRAM-SHA3-512和SCRAM-SHA3-512-PLUS。这两个机制是盐化挑战响应认证机制（SCRAM）的变体，使用SHA3-512作为哈希函数。相比SHA-1，SHA3-512具有更强的安全性，并且预测寿命更长。在TLS通道上使用SCRAM-SHA3-512-PLUS时，需要确保已协商过会话哈希扩展或使用会话恢复。当使用SCRAM-SHA3-512-PLUS时，如果使用TLS 1.2，则默认使用的“tls-unique”通道绑定仍然有效。当使用SCRAM-SHA3-512-PLUS时，如果使用TLS 1.3，“tls-exporter”通道绑定应该被默认使用。 此外，文中还介绍了SCRAM-SHA3-512-PLUS的安全考虑因素、IANA考虑要点以及参考文献。
  • Diff: 该文档注册了两个新的SASL（简单认证和安全层）机制：SCRAM-SHA3-512和SCRAM-SHA3-512-PLUS。它们是基于SHA3-512的安全挑战响应机密机制的变体。相较于旧版本，这些新机制的主要区别在于： 1. 使用SHA3-512作为HMAC()和H()函数的哈希算法。 2. 宣布的服务器哈希迭代次数应至少为10000。 3. 在TLS协议上使用了Session Hash扩展或会话重连。 此外，还指出了在移动设备等低性能系统上的应用限制，并强调了避免哈希迭代计数过小导致计算成本过高的重要性。 总的来说，这两个新机制增强了其安全性，并且在某些情况下可能具有更好的预测寿命。然而，对于移动设备和其他低性能系统，仍需要权衡哈希迭代计数值以确保安全性和效率。


5. draft-melnikov-scram-sha-512-05

  • Title: SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
  • Authors: Alexey Melnikov(alexey.melnikov@isode.com)
  • Summary: 本文注册了两个新的SASL机制：SCRAM-SHA-512和SCRAM-SHA-512-PLUS，它们是SCRAM协议的变体。SCRAM-SHA-512使用SHA-512哈希函数进行安全验证，并且需要至少10000次迭代才能保证安全性。SCRAM-SHA-512-PLUS的安全性比SCRAM-SHA-512更高，但是其计算成本相对较高。在使用TLS通道时，必须确保使用了会话哈希扩展（Session Hash Extension）或已使用了会话恢复。SCRAM-SHA-512-PLUS应该使用“tls-unique”频道绑定，在TLS 1.2版本下默认为“tls-unique”。当使用SCRAM-SHA-512-PLUS时，如果客户端未缓存ClientKey，则计算过程将花费大约15秒；但如果设置了适当的hash迭代计数，这个时间可以缩短到0.5秒以内。总之，SCRAM-SHA-512-PLUS是一个强安全性的SASL机制，但为了提高效率，建议设置合适的hash迭代计数。
  • Diff: 该标准文稿是关于在Internet-Draft中注册两个新的简单认证和安全层（SASL）机制：SCRAM-SHA-512 和 SCRAM-SHA-512-PLUS。这两种机制是基于哈希函数SHA-512的盐化挑战响应认证机制(SCRAM)的变体。它们具有更强的安全性，因为SHA-512比SHA-1更强大。此外，这两个机制都必须使用至少10000次迭代的Hash函数来确保其安全性。 在安全性方面，旧版文档强调了SCRAM-SHA-1和SCRAM-SHA-1-PLUS机制的预测寿命比SCRAM-SHA-1和SCRAM-SHA-1-PLUS机制要长，以及使用强安全机制如SHA-512时，应考虑移动设备等低性能系统的影响。 新版文档更新了SCRAM-SHA-512和SCRAM-SHA-512-PLUS的描述，并添加了对这些新机制的注册信息。新增的SCRAM-SHA-512-PLUS机制与旧版不同，因为它可以在TLS通道已协商会话哈希扩展或不使用会话重续的情况下使用。同时，旧版也讨论了使用SCRAM协议的TLS 1.2和1.3版本时，"tls-unique"频道绑定的默认值如何变化的问题。


6. draft-bichot-msync-17

  • Title: MSYNC
  • Authors: Sophie Bale(sophie.bale@broadpeak.tv), Remy Brebion(remy.brebion@broadpeak.tv), Guillaume Bichot(guillaume.bichot@broadpeak.tv)
  • Summary: (MSYNC)是用于将视频媒体对象传输到IP多播网络的一种协议。它适用于多媒体内容的IP多播传输，可以支持通用的HTTP适应性流（HAS）协议。在部署方面，MSYNC允许通过一个预安排容量规划的多播服务器与一个多播网关和多播客户端之间传输HAS流。 MSYNC是一种适合用于集成互联网服务提供商的宽带IP多播网络来提供IPTV服务的协议。它可以同时为多个接收器提供来自同一HAS协议的流，而无需改变这些设备之间的关系或连接方式。 该文档讨论了MSYNC的工作原理、协议格式以及其在实际应用中的工作流程。它还介绍了MSYNC的部署环境，包括如何在宽带IP多播网络上实现它的功能，并解释了如何确保MSYNC的安全性和性能。 总的来说，《多播同步协议》详细描述了MSYNC的功能及其在特定场景下的应用，提供了详细的配置信息和建议，有助于开发者更好地理解并实施这种协议。
  • Diff: 本文介绍了MSYNC协议，这是一种用于在IP多播网络上传输视频媒体对象的协议。与传统的单播或多播协议不同，MSYNC允许使用HTTP等无连接协议进行流式传输，并且可以跨多个多播组进行传输。此外，MSYNC还支持RTP作为数据包容器格式，使得它可以用于传输诸如CMAF这样的多媒体片段。 MSYNC的主要区别在于： 1. 支持多种编码方案：MSYNC支持多种编码方式，包括HLS、Apple HLS和MPEG DASH等。 2. 多样化的用户需求：MSYNC支持多种应用场景，包括广播、电视、OTT服务等。 3. 高效利用多播资源：MSYNC可以在多播网络上传输大量视频流，从而节省带宽。 4. 自动维护网络状态：MSYNC能够自动调整发送速率以适应网络状况的变化。 总的来说，MSYNC是一种高效灵活的多播传输协议，非常适合应用于各种媒体流的传输场景。