L'IETF appelle à mettre fin à l'expérimentation ARC : ce que cela signifie pour l'authentification des e-mails

L'IETF a publié un projet recommandant que ARC (Authenticated Received Chain) soit marqué comme « Obsolète » après 10 ans d'expérimentation. ARC avait été conçu pour préserver l'authentification des e-mails lorsque des intermédiaires comme les listes de diffusion et les services de transfert modifiaient les messages, mais n'a pas réussi à fournir une solution évolutive en raison de l'absence d'un système de réputation à l'échelle d'Internet. Les enseignements tirés de cette expérimentation seront intégrés dans DKIM2, le successeur de nouvelle génération de DKIM.

Pour les organisations, cela signifie qu'il faut continuer à se concentrer sur SPF, DKIM et DMARC comme fondement de la sécurité des e-mails, qui restent des exigences obligatoires imposées par les principaux fournisseurs de messagerie.

Red Sift OnDMARC aide les organisations à atteindre une application stricte complète de DMARC en 6 à 8 semaines, les protégeant contre l'usurpation d'identité et le phishing tout en maintenant la délivrabilité des e-mails à travers tous les intermédiaires et scénarios de transfert.

L'Internet Engineering Task Force (IETF) a publié un projet appelant à la conclusion de l'expérimentation ARC (Authenticated Received Chain) et recommandant que la RFC8617 soit marquée comme « Obsolète ». Cela marque la fin d'un effort de dix ans visant à résoudre l'un des défis les plus persistants de l'authentification des e-mails : que se passe-t-il lorsque des intermédiaires légitimes modifient les messages et compromettent DMARC.

Après le déploiement de DMARC, qui a aligné SPF et DKIM avec les domaines des auteurs et a fourni une application des politiques, une lacune critique est apparue : les modifications liées au transfert et aux listes de diffusion compromettaient fréquemment l'authentification, entraînant l'échec des vérifications DMARC pour des e-mails légitimes.

ARC a été introduit comme protocole expérimental pour résoudre ce problème en créant une « chaîne de traçabilité » cryptographique pour les e-mails. Le concept était simple : chaque intermédiaire traitant un message (listes de diffusion, services de transfert, passerelles) pouvait :

1. Enregistrer les résultats d'authentification observés
2. Signer ces observations de manière cryptographique
3. Créer une chaîne vérifiable montrant ce qui s'est passé le long du parcours du message

L'objectif était de permettre aux destinataires en aval de voir que, même si l'authentification actuelle pouvait être compromise, le message était légitime lors de son envoi initial.

ARC définissait trois champs d'en-tête que les intermédiaires pouvaient ajouter aux messages :

• ARC-Authentication-Results : Les résultats d'authentification observés par l'intermédiaire
• ARC-Message-Signature : Une signature du message et des en-têtes ARC précédents
• ARC-Seal : Une signature liant l'ensemble de la chaîne

Chaque gestionnaire ajoutait son propre ensemble de ces en-têtes, construisant une chaîne que les évaluateurs en aval pouvaient vérifier. Si la chaîne était valide, les destinataires pouvaient potentiellement faire confiance à la légitimité du message malgré les échecs d'authentification actuels.

Après 10 ans d'expérience opérationnelle, le projet de l'IETF identifie plusieurs raisons critiques expliquant pourquoi ARC n'a pas atteint ses objectifs :

ARC pouvait vérifier que les intermédiaires avaient participé à la chaîne, mais ne pouvait pas transmettre de confiance. Sans moyen de déterminer lesquels des milliers d'intermédiaires potentiels étaient dignes de confiance, les destinataires ne pouvaient pas ignorer en toute sécurité les échecs DMARC en se basant uniquement sur ARC. Les listes d'autorisation ad hoc se sont révélées insuffisantes et coûteuses à maintenir.

ARC montrait qu'un message avait été modifié, mais pas ce qui avait changé ni pourquoi. Cela laissait entièrement l'interprétation aux évaluateurs et à leur capacité à évaluer la réputation des intermédiaires — une charge qui s'est révélée opérationnellement impraticable à l'échelle d'Internet.

La séparation entre « vérification » et « confiance » a créé des risques. Les attaquants pouvaient acheminer des messages via des intermédiaires permissifs ou compromis pour obtenir un traitement favorable, contournant ainsi efficacement le système.

Le nombre d'intermédiaires et de services de transfert potentiels est vaste et en constante évolution. Maintenir des registres de réputation pour tous ces acteurs s'est révélé irréaliste, et après 10 ans, aucun système de réputation à l'échelle d'Internet n'a émergé — et aucun n'est prévu.

Le problème de transfert qui a motivé la création d'ARC reste réel. Lorsque des messages sont transférés via des listes de diffusion ou des règles de transfert automatique :

• SPF échoue car l'infrastructure de transfert apparaît comme l'adresse IP d'envoi
• DKIM échoue souvent lorsque les services de transfert modifient les en-têtes ou le corps du message
• DMARC échoue en conséquence, bloquant potentiellement des e-mails légitimes

Cependant, le projet de l'IETF précise clairement que l'approche d'ARC — s'appuyant sur la réputation des intermédiaires sans cadre de confiance évolutif — n'est pas la solution.

Au lieu de cela, les éléments utiles d'ARC (assertions signées concernant le traitement) seront intégrés dans DKIM2, le successeur proposé de DKIM. DKIM2 vise à traiter les attaques par rejeu, les schémas de routage modernes et le traitement par les intermédiaires de manière plus complète, sans nécessiter de chaînes de signatures parallèles ni de systèmes de réputation saut par saut.

• Continuer à se concentrer sur SPF, DKIM et DMARC : Les fondamentaux n'ont pas changé. SPF, DKIM et DMARC restent le fondement de l'authentification des e-mails et sont exigés par les principaux fournisseurs de messagerie, dont Google, Yahoo et Microsoft, pour les expéditeurs en masse.
• Ne pas déployer de nouvelles implémentations ARC : Le projet de l'IETF recommande qu'ARC ne soit plus déployé ni utilisé comme référence entre expéditeurs et destinataires distincts. Tout traitement ARC résiduel doit être considéré uniquement à titre diagnostique. Remarque : Sauf si votre organisation construit une infrastructure de messagerie, ceci n'est probablement pas pertinent.
• Se préparer pour DKIM2 : À mesure que DKIM2 se développe et intègre les enseignements tirés de l'expérimentation ARC, les organisations doivent se tenir informées de l'évolution des normes d'authentification des e-mails.
• Maintenir une application stricte de DMARC : Indépendamment du problème de transfert, DMARC en mode d'application (p=reject ou p=quarantine) reste la protection la plus efficace contre l'usurpation de domaine exact et les attaques de phishing.

Red Sift OnDMARC se concentre sur les besoins actuels des organisations : un déploiement rapide et fiable de SPF, DKIM et DMARC pour se protéger contre l'usurpation d'identité et maintenir la délivrabilité.

• Déploiement rapide : La plupart des organisations atteignent une application stricte complète de DMARC en 6 à 8 semaines grâce à des conseils automatisés et des tests en temps réel via Red Sift Investigate
• SPF dynamique : Contournez la limite de 10 recherches sans macros, garantissant la délivrabilité même à travers des infrastructures d'envoi complexes
• Gestion automatisée : Contrôlez les enregistrements SPF, DKIM, DMARC, BIMI et MTA-STS depuis un tableau de bord unique avec un seul changement DNS
• DNS Guardian : Surveillance continue des mauvaises configurations DNS et des attaques de sous-domaines qui contournent DMARC
• Dépannage assisté par IA : Red Sift Radar résout les problèmes d'authentification 10 fois plus rapidement grâce à des analyses pilotées par LLM
• Visibilité claire : Des tableaux de bord en temps réel transforment des rapports DMARC complexes en informations exploitables

Pourquoi les organisations choisissent Red Sift

Red Sift OnDMARC est la solution DMARC n°1 en EMEA avec une note de 4,9/5 sur G2, faisant confiance à plus de 1 200 organisations, dont Save the Children, ZoomInfo, Wise et Holland & Barrett.

Notre équipe de réussite client primée vous accompagne à chaque étape, de la mise en œuvre à l'application stricte complète, en veillant à ce que vous obteniez rapidement une protection sans perturber la livraison des e-mails légitimes.

La conclusion de l'expérimentation ARC renforce ce que les équipes de sécurité savent déjà : une authentification efficace des e-mails commence par une mise en œuvre correcte de SPF, DKIM et DMARC.

Red Sift OnDMARC rend cela accessible aux organisations de toutes tailles, grâce à une automatisation de niveau entreprise, des conseils d'experts et une technologie de premier plan.