# rfc

Published articles for rfc.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Proposal Raised To Finally Standardize Video Memory Stats Reporting Under Linux

DevFeed: [Proposal Raised To Finally Standardize Video Memory Stats Reporting Under Linux](<https://devfeed.tech/articles/proposal-raised-to-finally-standardize-video-memory-stats-reporting-under-linux-41403.md>)

Original publisher: [Read original article](<https://www.phoronix.com/news/Linux-Standardize-vRAM-Stats>)

Author: Michael Larabel

Published: 2026-09-17T15:17:24Z

Content type: news

Language: en

Sources: [Phoronix](<https://devfeed.tech/sources/phoronix.md>)

Topics: [Linux Kernel](<https://devfeed.tech/topics/linux-kernel.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Graphics](<https://devfeed.tech/topics/graphics.md>)

Tags: [desktop-linux](<https://devfeed.tech/tags/desktop-linux.md>), [drm](<https://devfeed.tech/tags/drm.md>), [graphics](<https://devfeed.tech/tags/graphics.md>), [igalia](<https://devfeed.tech/tags/igalia.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [linux](<https://devfeed.tech/tags/linux.md>), [linux-benchmarking](<https://devfeed.tech/tags/linux-benchmarking.md>), [linux-hardware-benchmarks](<https://devfeed.tech/tags/linux-hardware-benchmarks.md>), [linux-hardware-reviews](<https://devfeed.tech/tags/linux-hardware-reviews.md>), [linux-how-to](<https://devfeed.tech/tags/linux-how-to.md>), [linux-performance](<https://devfeed.tech/tags/linux-performance.md>), [linux-server-benchmarks](<https://devfeed.tech/tags/linux-server-benchmarks.md>), [open-source-graphics](<https://devfeed.tech/tags/open-source-graphics.md>), [phoronix](<https://devfeed.tech/tags/phoronix.md>), [phoronix-test-suite](<https://devfeed.tech/tags/phoronix-test-suite.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [ubuntu-benchmarks](<https://devfeed.tech/tags/ubuntu-benchmarks.md>), [ubuntu-hardware](<https://devfeed.tech/tags/ubuntu-hardware.md>), [vram](<https://devfeed.tech/tags/vram.md>)

### AI overview

A proposal led by Tvrtko Ursulin of Igalia would standardize cross-vendor video memory statistics reporting for Linux DRM drivers. The proposed sysfs interface would expose total and used memory for regions such as vRAM and GTT, with an AMDGPU implementation included for discussion.

### Source excerpt

The idea has been talked about before but in 2026 still hasn't made it to the mainline Linux kernel.... Standardized reporting of video memory statistics that would work across different vendors / kernel graphics drivers. A new proposal was raised today in an effort to get a standardized interface established...

## \[$\] Thread-identity switcheroo for io\_uring

DevFeed: [\[$\] Thread-identity switcheroo for io\_uring](<https://devfeed.tech/articles/thread-identity-switcheroo-for-io-uring-42126.md>)

Original publisher: [Read original article](<https://lwn.net/Articles/1094303/>)

Author: corbet

Published: 2026-09-17T13:49:59Z

Content type: article

Language: en

Sources: [LWN.net](<https://devfeed.tech/sources/lwn-net.md>)

Topics: [io\_uring](<https://devfeed.tech/topics/io-uring.md>), [execution](<https://devfeed.tech/topics/execution.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>)

Tags: [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [execution](<https://devfeed.tech/tags/execution.md>), [io-uring](<https://devfeed.tech/tags/io-uring.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [thread](<https://devfeed.tech/tags/thread.md>)

### AI overview

An RFC patch set proposes a new approach to preserving io_uring's guarantee that applications do not block during asynchronous execution. The proposal addresses kernel paths not designed for asynchronous execution and the performance cost of existing workarounds.

### Source excerpt

The io_uring subsystem is all about asynchronous execution; applications count on it to not block -- unless explicitly requested to. Within io_uring, maintaining the "never blocks" guarantee has sometimes been a challenge, given that many paths in the kernel were never designed for asynchronous execution. This problem has been worked around, but at a significant cost to performance. Now, io_uring maintainer Jens Axboe has posted an RFC patch set with a somewhat radical (and potentially scary) solution to the problem.

## RFC 10033: Hash-based Signatures: State and Backup Management

DevFeed: [RFC 10033: Hash-based Signatures: State and Backup Management](<https://devfeed.tech/articles/rfc-10033-hash-based-signatures-state-and-backup-management-41803.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10033.html>)

Published: 2026-09-15T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [hash](<https://devfeed.tech/topics/hash.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [DNSSEC](<https://devfeed.tech/topics/dnssec.md>)

Tags: [backup](<https://devfeed.tech/tags/backup.md>), [dnssec](<https://devfeed.tech/tags/dnssec.md>), [hash](<https://devfeed.tech/tags/hash.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [state](<https://devfeed.tech/tags/state.md>)

### AI overview

This French article explains an IETF RFC on stateful cryptographic algorithms, focusing on the need to track and back up signing state. It discusses hash-based signatures such as LMS, HSS, and XMSS, whose security depends on avoiding key reuse, particularly in post-quantum cryptography.

### Source excerpt

Certains algorithmes de cryptographie sont à état, c'est-à-dire que les programmes qui les utilisent doivent se souvenir des exécutions précédentes de l'algorithme ; refaire tourner l'algorithme dans les mêmes conditions serait une faille de sécurité. Cette nécessité de mémoriser un état complique évidemment leur utilisation. Ce nouveau RFC documente les bonnes pratiques à ce sujet.

## RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH

DevFeed: [RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH](<https://devfeed.tech/articles/rfc-10042-post-quantum-traditional-hybrid-key-exchange-with-the-module-lattice-based-key-encapsulation-mechanism-for-use-in-ssh-41805.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10042.html>)

Published: 2026-08-31T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [ssh](<https://devfeed.tech/topics/ssh.md>), [Post-Quantum](<https://devfeed.tech/topics/post-quantum.md>), [Security](<https://devfeed.tech/topics/security.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [ecdh](<https://devfeed.tech/tags/ecdh.md>), [hybrid](<https://devfeed.tech/tags/hybrid.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [quantum](<https://devfeed.tech/tags/quantum.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [security](<https://devfeed.tech/tags/security.md>), [ssh](<https://devfeed.tech/tags/ssh.md>)

### AI overview

This French article discusses RFC 10042, which standardizes post-quantum/traditional hybrid key exchange for SSH. It explains the use of ML-KEM with traditional algorithms to protect SSH communications against quantum-capable attackers and weaknesses in post-quantum algorithms.

### Source excerpt

Tout le monde (et son chat) se met à la cryptographie post-quantique en ce moment et plus précisément à des systèmes hybrides, c'est-à-dire utilisant à la fois un algorithme traditionnel (comme ECDH) et un algorithme post-quantique (comme ML-KEM). Ce RFC décrit l'échange de clés (echange-cles.html) avec un système hybride dans le protocole SSH.

## RFC 10001: Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments

DevFeed: [RFC 10001: Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments](<https://devfeed.tech/articles/rfc-10001-operational-guidelines-for-dns-transport-in-mixed-ipv4-ipv6-environments-41799.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10001.html>)

Published: 2026-08-31T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [Internet](<https://devfeed.tech/topics/internet.md>), [migration](<https://devfeed.tech/topics/migration.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [dns](<https://devfeed.tech/tags/dns.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [internet](<https://devfeed.tech/tags/internet.md>), [ipv4](<https://devfeed.tech/tags/ipv4.md>), [ipv6](<https://devfeed.tech/tags/ipv6.md>), [migration](<https://devfeed.tech/tags/migration.md>), [operational](<https://devfeed.tech/tags/operational.md>), [rfc](<https://devfeed.tech/tags/rfc.md>)

### AI overview

This article explains an IETF RFC recommending that DNS servers support queries over both IPv4 and IPv6. It describes the risks of fragmented name resolution in mixed, IPv4-only, and IPv6-only networks and notes that the guidance replaces RFC 3901.

### Source excerpt

Vous gérez des serveurs DNS (qu'ils soient des résolveurs (resolveur-dns.html) ou des serveurs faisant autorité (serveur-dns-faisant-autorite.html)) dans un environnement où il y a à la fois IPv4 et IPv6 ? Alors, ce RFC va vous aider. Il remplace le RFC 3901, qui avait été écrit pour un monde très différent, où IPv6 était marginal. Désormais, la recommandation est que tout serveur DNS doit pouvoir servir les requêtes avec les deux versions d'IP.

## RFC 10037: Registration Data Access Protocol (RDAP) Extension for DNS Time-to-Live (TTL) Values

DevFeed: [RFC 10037: Registration Data Access Protocol (RDAP) Extension for DNS Time-to-Live (TTL) Values](<https://devfeed.tech/articles/rfc-10037-registration-data-access-protocol-rdap-extension-for-dns-time-to-live-ttl-values-41804.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10037.html>)

Published: 2026-08-29T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [JSON](<https://devfeed.tech/topics/json.md>), [data](<https://devfeed.tech/topics/data.md>), [Perl](<https://devfeed.tech/topics/perl.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [data](<https://devfeed.tech/tags/data.md>), [dns](<https://devfeed.tech/tags/dns.md>), [json](<https://devfeed.tech/tags/json.md>), [perl](<https://devfeed.tech/tags/perl.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [ttl](<https://devfeed.tech/tags/ttl.md>)

### AI overview

This French article explains a new RFC that standardizes an RDAP extension for retrieving DNS TTL values associated with registered domain and name-server objects. It describes the JSON response property, clarifies that the value is the registry-recorded TTL rather than the resolver's remaining cache time, and notes support in several RDAP libraries.

### Source excerpt

Puisque le RFC 9803 étend le protocole d'avitaillement EPP pour ajouter des TTL spécifiques aux noms de domaine enregistrés, il était logique que le protocole d'interrogation RDAP permette d'obtenir cette information. C'est ce que permet l'extension normalisée dans ce nouveau RFC.

## RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3

DevFeed: [RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3](<https://devfeed.tech/articles/rfc-10024-post-quantum-traditional-pq-t-hybrid-key-agreement-mechanisms-for-tls-1-3-41802.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10024.html>)

Published: 2026-08-20T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [Post-Quantum](<https://devfeed.tech/topics/post-quantum.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [hybrid](<https://devfeed.tech/tags/hybrid.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [quantum](<https://devfeed.tech/tags/quantum.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [tls](<https://devfeed.tech/tags/tls.md>)

### AI overview

This article explains RFC 10024, which standardizes hybrid post-quantum and traditional key-agreement mechanisms for TLS. The mechanisms combine ML-KEM with traditional algorithms such as ECDH to provide protection against potential quantum and conventional cryptanalysis, while also discussing key sizes and FIPS compliance.

### Source excerpt

On met du post-quantique partout en ce moment. Ce court RFC normalise l'utilisation de clés hybrides (post-quantiques et traditionnelles) dans les échanges de clés de TLS.

## RFC 9852: New Protocols Using TLS Must Require TLS 1.3

DevFeed: [RFC 9852: New Protocols Using TLS Must Require TLS 1.3](<https://devfeed.tech/articles/rfc-9852-new-protocols-using-tls-must-require-tls-1-3-41810.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9852.html>)

Published: 2026-07-17T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [protocols](<https://devfeed.tech/topics/protocols.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [QUIC](<https://devfeed.tech/topics/quic.md>)

Tags: [ietf](<https://devfeed.tech/tags/ietf.md>), [internet](<https://devfeed.tech/tags/internet.md>), [protocols](<https://devfeed.tech/tags/protocols.md>), [quic](<https://devfeed.tech/tags/quic.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [tls](<https://devfeed.tech/tags/tls.md>), [version](<https://devfeed.tech/tags/version.md>)

### AI overview

This French article explains RFC 9852, which strongly advises designers of new cryptographic network protocols to require TLS 1.3 or later. It contrasts TLS 1.3 with TLS 1.2, discusses configuration and security weaknesses in TLS 1.2, notes QUIC's TLS 1.3 requirement, and mentions implications for post-quantum cryptography.

### Source excerpt

Si vous concevez des protocoles réseau utilisant la cryptographie, vous utiliserez souvent TLS. Dans ce cas, pour un nouveau protocole, n'ayant pas à gérer l'existant, l'IETF vous conseille fortement, dans ce RFC, d'exiger dans la définition du protocole qu'il faut au moins la version 1.3 de TLS.

## Les limites de la métrique " nombre d'octets " sur les réseaux informatiques

DevFeed: [Les limites de la métrique " nombre d'octets " sur les réseaux informatiques](<https://devfeed.tech/articles/les-limites-de-la-metrique-nombre-d-octets-sur-les-reseaux-informatiques-41829.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/metrique-trafic.html>)

Published: 2026-07-17T00:00:00Z

Content type: opinion

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Internet](<https://devfeed.tech/topics/internet.md>), [QUIC](<https://devfeed.tech/topics/quic.md>)

Tags: [akamai](<https://devfeed.tech/tags/akamai.md>), [amazon](<https://devfeed.tech/tags/amazon.md>), [google](<https://devfeed.tech/tags/google.md>), [internet](<https://devfeed.tech/tags/internet.md>), [meta](<https://devfeed.tech/tags/meta.md>), [netflix](<https://devfeed.tech/tags/netflix.md>), [quic](<https://devfeed.tech/tags/quic.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [tcp](<https://devfeed.tech/tags/tcp.md>)

### AI overview

This article examines the limitations of using byte counts to compare Internet traffic. It argues that byte volume can obscure strategic importance and considers alternatives such as flow counts and economic value, including for comparisons between public and private peering.

### Source excerpt

La présentation, le 16 juillet 2026, du rapport annuel de l'ARCEP sur l'état de l'Internet en France (https://www.arcep.fr/actualites/actualites-et-communiques/detail/n/rapport-annuel-tome3-160726.html) a été l'occasion de se poser la question : quand on compare quantitativement des choses sur l'Internet, par exemple l'appairage public et le transit, on utilise presque toujours comme métrique le nombre d'octets. Est-ce une bonne idée ?

## RFC 9954: Hybrid key exchange in TLS 1.3

DevFeed: [RFC 9954: Hybrid key exchange in TLS 1.3](<https://devfeed.tech/articles/rfc-9954-hybrid-key-exchange-in-tls-1-3-41812.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9954.html>)

Published: 2026-07-16T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [hybrid](<https://devfeed.tech/tags/hybrid.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [tls](<https://devfeed.tech/tags/tls.md>)

### AI overview

The article explains RFC 9954's hybrid key exchange for TLS, which combines a traditional algorithm with a post-quantum algorithm so an attacker would need to break both.

### Source excerpt

Dans le monde merveilleux de la cryptographie post-quantique (RFC 9958), un problème se pose : si en voulant éviter le Charybde des calculateurs quantiques, on tombe dans le Scylla d'un algorithme, certes post-quantique, mais pour lequel une attaque cryptanalytique est trouvée ? N'aurait-on pas lâché la proie pour l'ombre ? La solution, que ce RFC décrit pour le cas de l'échange de clés (echange-cles.html) dans TLS, est la cryptographie hybride : on utilise à la fois un algorithme traditionnel et un post-quantique (RFC 9794). Un éventuel attaquant devrait alors casser les deux pour réussir.

## RFC 9850: The SSLKEYLOGFILE Format for TLS

DevFeed: [RFC 9850: The SSLKEYLOGFILE Format for TLS](<https://devfeed.tech/articles/rfc-9850-the-sslkeylogfile-format-for-tls-41808.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9850.html>)

Published: 2026-07-16T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [ASCII](<https://devfeed.tech/topics/ascii.md>), [SSL](<https://devfeed.tech/topics/ssl.md>)

Tags: [ascii](<https://devfeed.tech/tags/ascii.md>), [communication](<https://devfeed.tech/tags/communication.md>), [format](<https://devfeed.tech/tags/format.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [ssl](<https://devfeed.tech/tags/ssl.md>), [tls](<https://devfeed.tech/tags/tls.md>), [wireshark](<https://devfeed.tech/tags/wireshark.md>)

### AI overview

This French article explains RFC 9850, which specifies the SSLKEYLOGFILE format for exporting TLS session secrets so packet analyzers such as Wireshark can decrypt and inspect network communication. It notes that the legacy name refers to SSL even though the format is used with TLS, and describes the file's text-based structure.

### Source excerpt

Déboguer une application réseau qui utilise le chiffrement est difficile. Le but du chiffrement est justement d'empêcher un tiers (par exemple l'analyseur de paquets) de regarder ce qui se passe. Une approche possible est de demander gentiment à l'application d'exporter ses clés de chiffrement dans un fichier que l'analyseur pourra importer pour ensuite déchiffrer la communication. Ce RFC décrit le format le plus répandu pour exporter ses clés, connu sous le nom de SSLKEYLOGFILE et très commun aujourd'hui.

## RFC 9851: TLS 1.2 is in Feature Freeze

DevFeed: [RFC 9851: TLS 1.2 is in Feature Freeze](<https://devfeed.tech/articles/rfc-9851-tls-1-2-is-in-feature-freeze-41809.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9851.html>)

Published: 2026-07-16T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [version](<https://devfeed.tech/topics/version.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [ECDSA](<https://devfeed.tech/topics/ecdsa.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [akamai](<https://devfeed.tech/tags/akamai.md>), [article](<https://devfeed.tech/tags/article.md>), [ecdsa](<https://devfeed.tech/tags/ecdsa.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [quantum](<https://devfeed.tech/tags/quantum.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [rsa](<https://devfeed.tech/tags/rsa.md>), [tls](<https://devfeed.tech/tags/tls.md>), [version](<https://devfeed.tech/tags/version.md>)

### AI overview

This French article explains that TLS 1.2 is now feature-frozen: it will receive no new functions, while ongoing development targets TLS 1.3. TLS 1.2 remains usable and may receive urgent security fixes and limited permitted updates. Post-quantum algorithm integration will apply to TLS 1.3.

### Source excerpt

Vous pouvez toujours utiliser la version 1.2 de TLS mais ne demandez pas des ajouts, des extensions, etc. Elle est désormais gelée, aucune nouvelle fonction ne sera ajoutée, tout le travail se fait désormais sur la meilleure version, la 1.3, normalisée dans le RFC 9846.

## RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key

DevFeed: [RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key](<https://devfeed.tech/articles/rfc-9973-tls-1-3-extension-for-using-certificates-with-an-external-pre-shared-key-41815.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9973.html>)

Published: 2026-07-16T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [certificates](<https://devfeed.tech/topics/certificates.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [certificates](<https://devfeed.tech/tags/certificates.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [security](<https://devfeed.tech/tags/security.md>), [tls](<https://devfeed.tech/tags/tls.md>)

### AI overview

This article explains RFC 9973, a TLS extension that allows a connection to combine certificate authentication with an external pre-shared key. The RFC replaces RFC 8773 and gives the mechanism standards status rather than experimental status.

### Source excerpt

L'authentification dans TLS se fait typiquement soit à partir d'un certificat, soit par une clé partagée à l'avance. Ce RFC spécifie une extension de TLS qui permet d'utiliser certificat et clé partagée à l'avance. Il remplace le RFC 8773 mais ne change pas grand'chose, la principale modification étant que ce nouveau RFC a le statut de norme (au lieu d'être considéré comme expérimental).

## RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3

DevFeed: [RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3](<https://devfeed.tech/articles/rfc-9846-the-transport-layer-security-tls-protocol-version-1-3-41807.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9846.html>)

Published: 2026-07-12T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Security](<https://devfeed.tech/topics/security.md>), [version](<https://devfeed.tech/topics/version.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [client](<https://devfeed.tech/topics/client.md>), [Internet](<https://devfeed.tech/topics/internet.md>), [QUIC](<https://devfeed.tech/topics/quic.md>)

Tags: [client](<https://devfeed.tech/tags/client.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [internet](<https://devfeed.tech/tags/internet.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [quic](<https://devfeed.tech/tags/quic.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [security](<https://devfeed.tech/tags/security.md>), [tls](<https://devfeed.tech/tags/tls.md>), [version](<https://devfeed.tech/tags/version.md>)

### AI overview

This French article explains RFC 9846, which updates the TLS 1.3 standard. It describes TLS as a mechanism for secure client-server communication over untrusted networks, including its relationship with TCP and QUIC, and introduces the protocol's complexity and components.

### Source excerpt

Ce RFC met à jour la norme de la version 1.3 du protocole de cryptographie TLS. Il n'y a pas de grand changement par rapport à son prédécesseur, le RFC 8446.

## RFC 9998: Report from the IAB/W3C Workshop on Age-Based Restrictions on Content Access

DevFeed: [RFC 9998: Report from the IAB/W3C Workshop on Age-Based Restrictions on Content Access](<https://devfeed.tech/articles/rfc-9998-report-from-the-iab-w3c-workshop-on-age-based-restrictions-on-content-access-41822.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9998.html>)

Published: 2026-07-03T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Internet](<https://devfeed.tech/topics/internet.md>), [W3C](<https://devfeed.tech/topics/w3c.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [article](<https://devfeed.tech/tags/article.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [internet](<https://devfeed.tech/tags/internet.md>), [report](<https://devfeed.tech/tags/report.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [w3c](<https://devfeed.tech/tags/w3c.md>)

### AI overview

This article discusses RFC 9998, the report of an IAB/W3C workshop on age-based restrictions for access to Internet services. It describes the workshop's focus on technical approaches, architecture, privacy, decentralization, and the potential consequences of age-verification systems.

### Source excerpt

En octobre 2025, l'IAB et le W3C ont organisé un atelier (https://datatracker.ietf.org/group/agews/about/) à Londres sur la restriction d'accès à des services Internet en fonction de l'âge. Ce RFC est le compte-rendu de l'atelier. En tant que compte-rendu, il n'exprime donc pas une position officielle de l'IAB.

## RFC 10005: BGP Community for link capacity

DevFeed: [RFC 10005: BGP Community for link capacity](<https://devfeed.tech/articles/rfc-10005-bgp-community-for-link-capacity-40166.md>)

Original publisher: [Read original article](<https://blog.j2sw.com/netops/rfc-10005-bgp-link-bandwidth/>)

Author: j2sw

Published: 2026-07-01T13:31:00Z

Content type: article

Language: en

Sources: [Justin Wilson (j2sw)](<https://devfeed.tech/sources/justin-wilson-j2sw.md>)

Topics: [BGP](<https://devfeed.tech/topics/bgp.md>), [standard](<https://devfeed.tech/topics/standard.md>), [Load Balancing](<https://devfeed.tech/topics/load-balancing.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [bgp](<https://devfeed.tech/tags/bgp.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [internet](<https://devfeed.tech/tags/internet.md>), [load-balancing](<https://devfeed.tech/tags/load-balancing.md>), [network](<https://devfeed.tech/tags/network.md>), [network-operations](<https://devfeed.tech/tags/network-operations.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [rfc-10005](<https://devfeed.tech/tags/rfc-10005.md>), [route](<https://devfeed.tech/tags/route.md>), [routers](<https://devfeed.tech/tags/routers.md>), [routing](<https://devfeed.tech/tags/routing.md>), [standard](<https://devfeed.tech/tags/standard.md>), [traffic](<https://devfeed.tech/tags/traffic.md>)

### AI overview

RFC 10005 defines a BGP extended community for carrying link bandwidth information in routes. When multiple BGP paths are eligible, routers can use the value to weight traffic according to link capacity, while normal best-path policy still determines route eligibility. The RFC is currently a draft.

### Source excerpt

RFC 10005 defines a BGP extended community that lets a router attach link bandwidth information to a route. Another router can use that value when it spreads traffic across multiple BGP paths. RFC 10005 matters because links are not always of the same capacity. This RFC provides routers with a standard way to carry bandwidth ... Read more The post RFC 10005: BGP Community for link capacity appeared first on Justin Wilson (j2sw).

## RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains

DevFeed: [RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains](<https://devfeed.tech/articles/rfc-9943-an-architecture-for-trustworthy-and-transparent-digital-supply-chains-41811.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9943.html>)

Published: 2026-07-01T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Security](<https://devfeed.tech/topics/security.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Certificate Transparency](<https://devfeed.tech/topics/certificate-transparency.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [article](<https://devfeed.tech/tags/article.md>), [certificate-transparency](<https://devfeed.tech/tags/certificate-transparency.md>), [digital](<https://devfeed.tech/tags/digital.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [security](<https://devfeed.tech/tags/security.md>)

### AI overview

This French article explains RFC 9943, an IETF architecture for trustworthy and transparent digital software supply chains. It discusses strong software traceability, its relationship to Certificate Transparency, and examples of supply-chain attacks including Trivy, litellm, and XZ.

### Source excerpt

Des attaques sur la chaine d'approvisionnement du logiciel, il y en a tout le temps. L'attaquant arrive à glisser du code malveillant dans un logiciel, en amont de son installation par la victime et, quand celle-ci fait tourner le logiciel, le code de l'attaquant est exécuté et paf. Il n'y a pas de solution miracle à ce problème mais on peut au moins essayer de fournir une traçabilité forte des logiciels, qui permet d'être sûr de ce qu'on fait tourner sur ses machines, et, dans le cas d'une enquête postérieure, de mieux comprendre ce qui s'est passé. Ce RFC décrit une architecture (https://scitt.io/), très inspirée du Certificate Transparency du RFC 9162.

## RFC 9980: Post-Quantum Cryptography in OpenPGP

DevFeed: [RFC 9980: Post-Quantum Cryptography in OpenPGP](<https://devfeed.tech/articles/rfc-9980-post-quantum-cryptography-in-openpgp-41817.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9980.html>)

Published: 2026-07-01T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Post-quantum cryptography](<https://devfeed.tech/topics/post-quantum-cryptography.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Post-Quantum](<https://devfeed.tech/topics/post-quantum.md>), [Encryption](<https://devfeed.tech/topics/encryption.md>), [Security, Privacy and Abuse Prevention](<https://devfeed.tech/topics/security-privacy-and-abuse-prevention.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [Git](<https://devfeed.tech/topics/git.md>), [apt](<https://devfeed.tech/topics/apt.md>)

Tags: [apt](<https://devfeed.tech/tags/apt.md>), [cryptography](<https://devfeed.tech/tags/cryptography.md>), [ecdsa](<https://devfeed.tech/tags/ecdsa.md>), [git](<https://devfeed.tech/tags/git.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [post-quantum-cryptography](<https://devfeed.tech/tags/post-quantum-cryptography.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [rsa](<https://devfeed.tech/tags/rsa.md>)

### AI overview

This article discusses RFC 9980, which specifies how NIST-standardized post-quantum algorithms can be used in the OpenPGP format. It explains the motivation for early deployment, including the long-term protection of encrypted and signed messages, and notes challenges involving hybrid keys and confidence in newer algorithms.

### Source excerpt

Vous le savez, le jour où des CRQC (Cryptographically Relevant Quantum Computer, un calculateur quantique capable de calculs non triviaux, contrairement aux modèles d'aujourd'hui) seront disponibles, la cryptographie sera sérieusement secouée. Il est donc important de travailler dès maintenant sur des algorithmes pour l'après-quantique, et de les intégrer dans les protocoles et les formats utilisés sur l'Internet. Ce RFC documente l'utilisation des algorithmes normalisés par le NIST dans le format OpenPGP.

## RFC 9958: Post-Quantum Cryptography for Engineers

DevFeed: [RFC 9958: Post-Quantum Cryptography for Engineers](<https://devfeed.tech/articles/rfc-9958-post-quantum-cryptography-for-engineers-41813.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9958.html>)

Published: 2026-06-20T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Post-quantum cryptography](<https://devfeed.tech/topics/post-quantum-cryptography.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Post-Quantum](<https://devfeed.tech/topics/post-quantum.md>), [Security, Privacy and Abuse Prevention](<https://devfeed.tech/topics/security-privacy-and-abuse-prevention.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [Internet](<https://devfeed.tech/topics/internet.md>), [ECDSA](<https://devfeed.tech/topics/ecdsa.md>)

Tags: [cryptography](<https://devfeed.tech/tags/cryptography.md>), [ecdsa](<https://devfeed.tech/tags/ecdsa.md>), [https](<https://devfeed.tech/tags/https.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [internet](<https://devfeed.tech/tags/internet.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [post-quantum-cryptography](<https://devfeed.tech/tags/post-quantum-cryptography.md>), [publication](<https://devfeed.tech/tags/publication.md>), [quantum](<https://devfeed.tech/tags/quantum.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [rsa](<https://devfeed.tech/tags/rsa.md>)

### AI overview

This French article explains RFC 9958, which guides engineers implementing post-quantum cryptographic algorithms in Internet software and protocols. It assumes familiarity with the algorithms themselves and focuses on their practical integration, while describing the quantum-computing threat to traditional systems such as RSA and ECDSA.

### Source excerpt

Tout le monde parle (https://www.afnic.fr/observatoire-ressources/papier-expert/en-route-vers-la-journee-du-conseil-scientifique-2025/) des calculateurs quantiques et du risque qu'ils font peser sur la cryptographie traditionnelle. La solution ? Remplacer ces algorithmes par des algorithmes post-quantiques, c'est-à-dire résistant aux calculateurs quantiques. Ces algorithmes existent déjà, plusieurs sont normalisés et beaucoup ont déjà été mis en œuvre dans des programmes. Mais les intégrer dans les protocoles de l'Internet n'est pas trivial. Ce RFC vise à guider les ingénieur-es qui vont appliquer ces algorithmes post-quantiques à des logiciels et des protocoles du monde de l'Internet.

## RFC 10008: The HTTP QUERY Method

DevFeed: [RFC 10008: The HTTP QUERY Method](<https://devfeed.tech/articles/rfc-10008-the-http-query-method-41800.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/10008.html>)

Published: 2026-06-16T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [http query](<https://devfeed.tech/topics/http-query.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [http](<https://devfeed.tech/tags/http.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [query](<https://devfeed.tech/tags/query.md>), [rfc](<https://devfeed.tech/tags/rfc.md>)

### AI overview

The article explains RFC 10008, which standardizes the HTTP QUERY method. QUERY carries a request body like POST while retaining GET-like idempotent semantics, enabling repeatable and cacheable search-style requests.

### Source excerpt

Ce n'est pas tous les jours qu'on normalise une nouvelle méthode HTTP. Bienvenue, donc, à QUERY, qui rejoint des méthodes bien plus anciennes comme GET et POST. QUERY peut être décrit comme " GET mais avec un corps dans la requête ". Comme GET, elle est idempotente et donc sûre à répéter.

## RFC 9975: Clarifications on CDS/CDNSKEY and CSYNC Consistency

DevFeed: [RFC 9975: Clarifications on CDS/CDNSKEY and CSYNC Consistency](<https://devfeed.tech/articles/rfc-9975-clarifications-on-cds-cdnskey-and-csync-consistency-41816.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9975.html>)

Published: 2026-05-28T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [DNSSEC](<https://devfeed.tech/topics/dnssec.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [consistency](<https://devfeed.tech/topics/consistency.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [consistency](<https://devfeed.tech/tags/consistency.md>), [dnssec](<https://devfeed.tech/tags/dnssec.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [systems](<https://devfeed.tech/tags/systems.md>)

### AI overview

This French article explains RFC 9975, which clarifies the security precautions needed when automating DNSSEC delegation changes through CDS and CDNSKEY records, as well as authoritative nameserver changes through CSYNC. It focuses on inconsistent responses from authoritative servers and related risks.

### Source excerpt

Pour compléter un processus de sécurisation des noms de domaine avec DNSSEC, il faut transmettre au domaine parent votre clé publique. Le faire manuellement via l'interface Web du BE n'est pas pratique donc il existe un moyen d'automatiser cela, les CDS/CDNSKEY, moyen décrit dans le RFC 7344. Mais attention à la sécurité ! Ce moyen n'est sûr que si on suit quelques précautions, décrites dans ce nouveau RFC.

## RFC 9987: SSH Agent Protocol

DevFeed: [RFC 9987: SSH Agent Protocol](<https://devfeed.tech/articles/rfc-9987-ssh-agent-protocol-41819.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9987.html>)

Published: 2026-05-28T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [OpenSSH](<https://devfeed.tech/topics/openssh.md>), [ssh](<https://devfeed.tech/topics/ssh.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [client](<https://devfeed.tech/topics/client.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>)

Tags: [client](<https://devfeed.tech/tags/client.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [openssh](<https://devfeed.tech/tags/openssh.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [ssh](<https://devfeed.tech/tags/ssh.md>)

### AI overview

This French article explains RFC 9987, which standardizes the long-established SSH Agent Protocol. It describes how the agent stores private keys, handles signing requests, and communicates with clients through a client-server protocol using TLV messages.

### Source excerpt

Voici encore un RFC qui normalise quelque chose qui existait depuis longtemps : le protocole Agent de SSH.

## RFC 9982: JSContact Version 2.0: A JSON Representation of Contact Data

DevFeed: [RFC 9982: JSContact Version 2.0: A JSON Representation of Contact Data](<https://devfeed.tech/articles/rfc-9982-jscontact-version-2-0-a-json-representation-of-contact-data-41818.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/9982.html>)

Published: 2026-05-28T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [JSON](<https://devfeed.tech/topics/json.md>), [format](<https://devfeed.tech/topics/format.md>), [version](<https://devfeed.tech/topics/version.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [identifier](<https://devfeed.tech/topics/identifier.md>), [object](<https://devfeed.tech/topics/object.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [article](<https://devfeed.tech/tags/article.md>), [format](<https://devfeed.tech/tags/format.md>), [identifier](<https://devfeed.tech/tags/identifier.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [json](<https://devfeed.tech/tags/json.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [version](<https://devfeed.tech/tags/version.md>)

### AI overview

This article explains JSContact Version 2.0, a JSON format for representing contact entities. The only change from version 1 is that the previously mandatory uid member is now optional, but that backward-incompatible change requires a new format version.

### Source excerpt

Voici la version 2 du format de représentation d'entités (personnes ou organisations) JSContact (RFC 9553). En fait, ce numéro de version est trompeur, il n'y a qu'un seul changement, le membre "uid" qui était obligatoire devient facultatif. Mais ce petit changement, qui casse la compatibilité, oblige à changer de numéro de version.

## RFC 33: New Host-Host Protocol

DevFeed: [RFC 33: New Host-Host Protocol](<https://devfeed.tech/articles/rfc-33-new-host-host-protocol-41806.md>)

Original publisher: [Read original article](<https://www.bortzmeyer.org/33.html>)

Published: 2026-05-26T00:00:00Z

Content type: article

Language: fr

Sources: [Blog de Stéphane Bortzmeyer](<https://devfeed.tech/sources/blog-de-stephane-bortzmeyer.md>)

Topics: [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Network](<https://devfeed.tech/topics/network.md>), [communications](<https://devfeed.tech/topics/communications.md>), [Internet](<https://devfeed.tech/topics/internet.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [article](<https://devfeed.tech/tags/article.md>), [communications](<https://devfeed.tech/tags/communications.md>), [internet](<https://devfeed.tech/tags/internet.md>), [messages](<https://devfeed.tech/tags/messages.md>), [network](<https://devfeed.tech/tags/network.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [rfc](<https://devfeed.tech/tags/rfc.md>), [tcp-ip](<https://devfeed.tech/tags/tcp-ip.md>)

### AI overview

This French article examines RFC 33 from 1970, which defined an early host-to-host protocol for ARPANET. It discusses the expansion of network addresses, message structure, virtual connections, and the protocol later known as NCP, which was eventually replaced by TCP/IP.

### Source excerpt

Continuons avec des vieux RFC. Ce RFC de 1970 se distinguait par une augmentation spectaculaire de la taille des adresses réseau : elles passaient de 5 à 8 bits.

[Next page](<https://devfeed.tech/tags/rfc.md?cursor=WyIyMDI2LTA1LTI2VDAwOjAwOjAwKzAwOjAwIiwgIjc4OTQ3OTRiLTE5OTctNDViMy1iOTRhLWY4OTJmYjgxODc3MCJd>)