<?xml version="1.0" encoding="UTF-8" ?> <rss version="2.0"> <channel> <title>Recent RFCs</title> <link>https://www.rfc-editor.org/</link> <description>Recently published RFCs</description> <language>en-us</language> <lastBuildDate>Fri, 14 Feb 2025 15:11:26 -0800</lastBuildDate> <item> <title>RFC 9714: Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method</title> <link>https://www.rfc-editor.org/info/rfc9714</link> <description>This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow-based packet loss, delay, and jitter measurements on MPLS traffic.</description> </item> <item> <title>RFC 9729: The Concealed HTTP Authentication Scheme</title> <link>https://www.rfc-editor.org/info/rfc9729</link> <description>Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme.</description> </item> <item> <title>RFC 9609: Initializing a DNS Resolver with Priming Queries</title> <link>https://www.rfc-editor.org/info/rfc9609</link> <description>This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers. This document obsoletes RFC 8109.</description> </item> <item> <title>RFC 9734: X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs</title> <link>https://www.rfc-editor.org/info/rfc9734</link> <description>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines an Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates</description> </item> <item> <title>RFC 9690: Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)</title> <link>https://www.rfc-editor.org/info/rfc9690</link> <description>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. This document obsoletes RFC 5990.</description> </item> <item> <title>RFC 9716: Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks</title> <link>https://www.rfc-editor.org/info/rfc9716</link> <description>The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. A Segment Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks. This is achieved through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes.</description> </item> <item> <title>RFC 9735: Locator/ID Separation Protocol (LISP) Distinguished Name Encoding</title> <link>https://www.rfc-editor.org/info/rfc9735</link> <description>This document defines how to use the Address Family Identifier (AFI) 17 &quot;Distinguished Name&quot; in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.</description> </item> <item> <title>RFC 9701: JSON Web Token (JWT) Response for OAuth Token Introspection</title> <link>https://www.rfc-editor.org/info/rfc9701</link> <description>This specification proposes an additional response secured by JSON Web Token (JWT) for OAuth 2.0 Token Introspection.</description> </item> <item> <title>RFC 9700: Best Current Practice for OAuth 2.0 Security</title> <link>https://www.rfc-editor.org/info/rfc9700</link> <description>This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure.</description> </item> <item> <title>RFC 9704: Establishing Local DNS Authority in Validated Split-Horizon Environments</title> <link>https://www.rfc-editor.org/info/rfc9704</link> <description>When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver. DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains.</description> </item> <item> <title>RFC 9717: A Routing Architecture for Satellite Networks</title> <link>https://www.rfc-editor.org/info/rfc9717</link> <description>Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics. This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes. This document presents the author's view and is neither the product of the IETF nor a consensus view of the community.</description> </item> <item> <title>RFC 9712: IETF Meeting Venue Requirements Review</title> <link>https://www.rfc-editor.org/info/rfc9712</link> <description>Following a review of the IETF meeting venue requirements, this document updates RFC 8718 (&quot;IETF Plenary Meeting Venue Selection Process&quot;), clarifies how the IETF Administration Support Activity (IASA) should interpret some elements of RFC 8718, and specifies a replacement exploratory meeting process, thereby updating RFC 8719 (&quot;High-Level Guidance for the Meeting Policy of the IETF&quot;).</description> </item> <item> <title>RFC 9715: IP Fragmentation Avoidance in DNS over UDP</title> <link>https://www.rfc-editor.org/info/rfc9715</link> <description>The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS.</description> </item> <item> <title>RFC 9718: DNSSEC Trust Anchor Publication for the Root Zone</title> <link>https://www.rfc-editor.org/info/rfc9718</link> <description>The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. This document obsoletes RFC 7958.</description> </item> <item> <title>RFC 9698: The JMAPACCESS Extension for IMAP</title> <link>https://www.rfc-editor.org/info/rfc9698</link> <description>This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client.</description> </item> </channel> </rss>