【每日文稿】2024-12-07
今日共有6篇文稿更新，涉及3个area里的5个WG
ART
emailcore
- Title: Simple Mail Transfer Protocol
- Authors: Dr. John C. Klensin(john-ietf@jck.com)
- Summary: 本文是关于简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)的基本协议。它整合了过去的一些文档，如RFC 5321、RFC 1846等，并对它们进行了更新和澄清。主要讨论了以下几点： 1. 定义了电子信件传输的目标：电子邮件系统通过TCP网络进行传输。 2. 历史背景：介绍SMTP的历史和演变过程。 3. 相关文档：列举了与SMTP相关的其他文档，包括域名解析和邮件交付协议等。 4. 主要功能：SMTP提供了基本的电子邮件传输服务，包括发送、接收和存储邮件等功能。 5. 未来展望：描述了将来可能会添加的功能，如安全扩展等。 总的来说，本文是对SMTP历史和当前状态的一种回顾和总结，旨在为未来的邮件传输提供指导。
- Diff: 该文档是关于互联网电子邮件传输的基本协议规范。它（包括文本）整合了从RFC 821 [6]到最新版RFC 5321的许多先前文档，并澄清了许多之前文档中的部分功能。文档不包含新的或改变现有功能的功能，但删除了一些冗余信息和注释以使文档更简洁。 与旧版不同之处在于： 1. 删除了过多冗长的文档注释和标题，以便于最后提交为RFC标准。 2. 在历史版本中提供了更多的细节和更新的信息，如邮件系统、代理服务器等扩展性方面，但这些信息未被重新编写或整合进当前版本中。 3. 强调了SMTP作为发送和接收邮件的主要工具，但也介绍了其他相关协议，例如POP和IMAP。 总的来说，这个文档旨在简化并整理已有的信息，使其更容易理解且对实际操作更加有用。
mailmaint
- Title: IMAP UIDBATCHES Extension
- Authors: Daniel Eggert(deggert@apple.com)
- Summary: 本文定义了一个扩展到互联网消息访问协议（IMAP）的功能，以从服务器检索用户的UID。这个功能允许用户根据需要划分邮件包，以便更有效地使用资源和响应大小。例如，可以请求特定数量的消息分发到指定大小的批次，这样就可以在每次命令上操作较少的消息数，从而改善控制和响应大小。 本文总结了该扩展的优点：它可以提供一个特殊的命令来解决两个问题：对于许多服务器，UID搜索命令指定序列号可能很昂贵；并且UIDONLY扩展不允许使用序列号，使得客户端无法将命令拆分为批量大小适合其客户端和服务器的批次数。 此外，本文讨论了与部分扩展、UIDONLY扩展和搜索结果扩展的交互，并指出了服务器支持这两个扩展时，应限制每个命令处理的最大消息数以及返回UID的数量。这些限制有助于确保代码的可维护性，并避免引入新的实施错误。
mlcodec
- Title: Integration of Speech Codec Enhancement Methods into the Opus Codec
- Authors: Jan Buethe(jan.buethe@googlemail.com), Jean-Marc Valin(jeanmarcv@google.com)
- Summary: 该文档主要讨论了如何将语音编码增强方法整合到Opus编码器中。为了确保兼容性，必须考虑对Opus解码器的影响。首先，需要测试算法的效果以确定其是否提高了质量，并且对于新添加的编码模式（如扩展和非扩展），在集成到Opus解码器之前还需要进行主观评估。此外，还需考虑编码自由度以及新的编码方式可能带来的潜在收益，从而避免导致旧式解码器无法正常工作的情况。 该文档还提出了编码能力的要求，包括测试数据、目标比特率等参数，并详细描述了这些要求的目的。最后，还讨论了相关标准的适用性和建议，提供了实现方案和注意事项。 总的来说，该文档旨在为实施语音编码增强提供指导，确保系统的兼容性和稳定性。
OPS
grow
- Title: Peering API
- Authors: Carlos Aguado(caguado@infra.structur.es), Matt Griswold(grizz@20c.com), Jenny Ramseyer(ramseyer@fb.com), Arturo L. Servin(arturo.servin@gmail.com), Tom Strickx(tstrickx@cloudflare.com)
- Summary: 本文提出了一种网络级别的API标准，用于自动化自治系统之间的互联网路由交换。这个API提供了一个标准化的请求（设置公共或私有连接）、验证会话状态和列表潜在连接位置的功能。它基于PeeringDB OIDC认证，以满足行业标准的需求。此外，还讨论了未来的私人连接、替代身份验证方法以及维护等细节。 主要贡献包括： 1. 提出了一个标准的API，简化了自治系统的互联配置。 2. 包含了一些公共端点，如公共或私有连接，资源管理等。 3. 鼓励自动化网络配置，但不强制完全自动化使用该API。 4. 定义了一些数据类型，并详细描述了API端点。 5. 提供了一些关于API使用的建议，比如如何实现自动化的维护过程。 总结了这篇文稿的主要目标是简化网络级别的互联，提高效率并减少人工干预。然而，为了实现这一目标，作者也指出需要更多的工作来考虑私人连接、替代身份验证方法和其他可能的应用场景。
- Title: Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers
- Authors: Job Snijders(job@sobornost.net), Stavros Konstantaras(stavros.konstantaras@ams-ix.net), Mo Shivji(moyaze@linx.net)
- Summary: 本文提出了一项建议，即避免在互联网交换点（IXP）路由服务器上使用BGP扩展社区。这一建议旨在帮助全球互联网路由系统的性能，并保护IXP参与者免受配置错误的影响。该建议特别针对IPv4网络和IXP运营商支持BGP扩展社区的情况。此外，文稿还提供了关于如何处理BGP扩展社区的方法，以及如何替换这些配置以使用更大规模的社区。 尽管BGP扩展社区在过去被用于4-octet自治系统号码（ASN）的支持，但随着BGP大规模社区标准的引入，所有公共互联网部署都已采用此标准。然而，目前仍有IP网络和IXP运营商继续支持BGP扩展社区用于IXP路由服务器信号目的。因此，作者推荐IXP运营商应使用更大规模的社区替代现有的配置。此外，文中提到了一些关于安全性的考虑，但没有具体的安全措施提到。
- Diff: 该文档提出了一个建议，避免在互联网交换点（IXP）路由服务器使用BGP扩展社区（Extended Communities），以帮助提高全球互联网路由系统的性能，并防止参与者误配置。与旧版相比，新版本引入了以下主要区别： 1. 更换为使用大型社区（Large Communities）来替代BGP扩展社区。 2. 提供了一个明确的时间线让客户过渡到大型社区。 3. 洗牌BGP扩展社区，在L3VPN方向清除那些用于L3VPN目的的扩展社区。 这些变化旨在减少对路由系统的压力，同时保护参与者的配置安全性。
SEC
suit
- Title: Encrypted Payloads in SUIT Manifests
- Authors: Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Russ Housley(housley@vigilsec.com), Brendan Moran(brendan.moran.ietf@gmail.com), David Brown(david.brown@linaro.org), Ken Takayama(11kenterada@gmail.com)
- Summary: 本文主要讨论了在SUIT MANIFEST中对软件、固件、机器学习模型和个人数据进行加密的技术。文稿介绍了两种用于分发密钥的方法：AES Key Wrap（AES-KW）和Ephemeral-Static Diffie-Hellman（ES-DH）。这两种方法都需要随机生成密钥，但是AES-KW使用公钥密码学，而ES-DH使用对称密码。此外，文稿还提供了两个部署选项来实现AES-KW和ES-DH的分发。 对于AES-KW，如果所有接收者共享相同的KEK，则可以将CEK仅发送给一个COSE_recipient结构，并且该结构包含通过KEK加密的CEK。然而，这种做法强烈不建议。如果接收者有不同的KEK，则需要为每个接收者创建多个COSE_recipient结构，其中每个结构都包含通过不同KEK加密的CEK。 而对于ES-DH，如果每个接收者具有唯一的私有公钥对，则可以将CEK仅发送给一个COSE_recipient结构。否则，可以为每个接收者创建多个COSE_recipient结构，每个结构包含通过特定KEK加密的CEK。 为了确保高安全性的使用AES Key Wrap，需要保护KEK的机密性，防止攻击者获得其值并加密和发送到所有受支持的接收者。为了保护源代码的安全，确保反汇编工具无法访问。 在分发内容时，可以考虑采用两层manifest系统以减少签名验证次数，或者考虑使用不同的CEK和KEK分别给定的不同接收者。这可以提供更好的威胁分析和更少的交互操作。
- Diff: 这篇新版本的英文标准文稿，相比旧版，在内容和结构上有以下几点主要区别： 1. 在架构部分，新增了两个加密扩展方法：Ephemeral-Static Diffie-Hellman（ES-DH）和AES Key Wrap（AES-KW）。它们分别使用公钥密码学和前预共享密钥（KEK），在加密过程中分别实现了不同的加密方式。 2. 增加了加密指令（Directive Write 和 Directive Copy），用于解密指定内容或组件中的数据。这些指令与之前的方法不同，需要额外的信息（如加密信息和解密指令等）来支持。 3. 新增了一个新的密钥分配扩展字段（SUIT_Encryption_Info），用于描述内容分发的方法、参数以及密钥的生成过程。 4. 对于ES-DH，增加了两个部署选项：如果所有受保护者都共享相同的KEK，则可以通过一个COSE_recipient结构包含加密的CEK；或者每个受保护者单独拥有各自的KEK，然后通过一系列循环为每个受保护者创建相应的CEK。这样可以减少共享KEK带来的威胁。 综上所述，相较于旧版，新版本引入了更多的加密扩展方法，丰富了密钥管理机制，并且提供了更灵活的部署选项，以适应各种应用场景的需求。