Résumé

  • Le RFC 9852 / BCP 195, coécrit par Rich Salz et Nimrod Aviram, demande à un nouveau protocole utilisant TLS de présumer TLS 1.3 disponible et de le spécifier par défaut. Cette obligation vise le texte du protocole en cours de conception.
  • Elle n’est pas un reçu émis par un endpoint actif. Version négociée, configuration, authentification du pair, acceptation par l’application et reprise restent des faits séparés. Le RFC exclut explicitement DTLS de cette prescription.

Dans les standards, « exiger » est un verbe précieux : il empêche qu’un choix déjà éclairé soit présenté comme indifférent. Il ne transforme pourtant pas la prescription en observation. Lire une exigence normative comme le constat d’un déploiement achevé revient à faire dire au document ce qu’il n’a jamais mesuré.

RFC 9852, New Protocols Using TLS Must Require TLS 1.3, est une Best Current Practice de l’IETF, BCP 195. Rich Salz et Nimrod Aviram y sont désignés comme auteurs, sans que l’article attribue à Salz seul un résultat de consensus. Le document répond à une question précise : que doit annoncer une nouvelle spécification qui utilise TLS ? Elle doit considérer TLS 1.3 disponible et spécifier TLS 1.3 comme valeur par défaut.

Cette réponse ne ferme pas les questions d’exploitation. Un texte peut exiger TLS 1.3 tandis qu’il reste à observer quelle version un client et un endpoint particuliers ont réellement négociée. La règle de conception est distincte de la politique locale qui choisit une configuration, de la chaîne d’authentification appropriée, du comportement applicatif après la négociation et de la trace qui montre qu’un incident a été vu puis repris. Ce sont des responsabilités différentes, pas des lacunes du BCP.

La frontière DTLS est tout aussi instructive. Le RFC dit que sa prescription concerne TLS seulement ; DTLS 1.3 n’étant pas largement disponible ou déployé, elle ne s’applique à DTLS dans aucune version. Réduire cela à « TLS 1.3 obligatoire » efface la condition qui rend la recommandation exacte.

Le document explique que TLS 1.3 est largement utilisé, bénéficie de preuves de sécurité complètes et corrige des faiblesses de confidentialité et de sécurité de TLS 1.2. Il reconnaît aussi que TLS 1.2 peut offrir de bonnes propriétés avec une configuration adaptée, souvent sur mesure. Les considérations post-quantiques motivent la direction, mais le RFC place hors de son périmètre la décision de savoir quand une application donnée doit employer la cryptographie post-quantique. Ce sont des raisons d’écrire une règle, non un relevé d’un parc réel.

La Primauté du code en fonctionnement demande donc une chaîne explicite. La BCP prouve la règle de conception. La configuration prouve l’intention locale. L’observation de négociation prouve un fait de connexion. Les traces d’authentification et d’application prouvent autre chose encore. Les joindre sans les confondre permet de dire à la fois qu’un protocole est correctement spécifié et que les limites d’une affirmation sur son exécution restent visibles.

La pratique est simple : l’auteur applique BCP 195 lorsqu’il définit un nouveau protocole TLS ; l’opérateur ne déclare un déploiement que sur des observations des endpoints concernés, de leur politique, de l’authentification nécessaire, du résultat applicatif et de la reprise. La norme et le système s’éclairent alors mutuellement sans se substituer l’un à l’autre.

Sources