<?xml version="1.0" encoding="utf-8"?>
<rfcdesc title="New Protocols Using TLS Must Require TLS 1.3"
	 num="9852" status="bcp" wg="uta">
  <authors><author>R. Salz (Akamai
  Technologies)</author><author>N. Aviram</author></authors>
  <rfcdate><month>July</month><year>2026</year></rfcdate>
  <date>2026-07-17</date>
<content>
  <p>Si vous concevez des <wikipedia name="Protocole de communication">protocoles</wikipedia> réseau
  utilisant la <wikipedia>cryptographie</wikipedia>, vous utiliserez
  souvent <wikipedia name="Transport Layer
  Security">TLS</wikipedia>. Dans ce cas, pour un nouveau protocole,
  n'ayant pas à gérer l'existant, l'<wikipedia name="Internet
  Engineering Task Force">IETF</wikipedia> vous conseille fortement,
  dans ce <wikipedia name="Request for comments">RFC</wikipedia>,
  d'exiger dans la définition du protocole qu'il faut au moins la
  version 1.3 de TLS.</p>
  <p><wikipedia name="Transport Layer Security">TLS</wikipedia> 1.3
  (<rfc num="9846" local="true"/>) est largement déployé (vous
  trouverez difficilement un serveur Internet qui n'ait que la version
  précédente, la 1.2, normalisée dans le <rfc num="5246"
  local="true"/>), a de meilleures preuves de sécurité, et protège
  mieux. Il est donc raisonnable de le définir comme version
  minimum. Attention, ce <wikipedia name="Request for
  comments">RFC</wikipedia> est destiné aux gens qui conçoivent des
  protocoles réseau, par exemple à l'<wikipedia name="Internet
  Engineering Task Force">IETF</wikipedia>, pas à
  l'<wikipedia name="Administrateur réseau">administrateur réseaux</wikipedia> de terrain. Celui-ci
  ou celle-ci peut continuer à utiliser TLS 1.2.</p>
  <p>La section 6 de notre RFC détaille les faiblesses de TLS 1.2, en
  remarquant qu'on peut configurer TLS 1.2 de manière sûre (couper la
  <link local="tls-renego">renégociation</link>, désactiver les
  algorithmes de cryptographie faibles, etc) mais que ce n'est pas
  toujours fait en pratique. Et bien des failles de sécurité ont
  frappé 1.2, alors que 1.3 n'y était pas vulnérable (on parle bien
  d'une faille du protocole, pas d'un programme particulier mettant en
  œuvre ce protocole). C'était par exemple le cas de <link
  local="beast-tls">Beast</link>.</p>
  <p>Certains protocoles ont déjà pris cette décision d'exiger TLS
  1.3, par exemple <wikipedia>QUIC</wikipedia> (<rfc num="9001"
  local="true"/>), qui impose de couper tout de suite la connexion si
  l'autre partie ne fait pas de 1.3. D'autres n'ont pas encore sauté
  le pas, ainsi, <wikipedia name="DNS over TLS">DoT</wikipedia> (<rfc num="8310"
  local="true"/>) permet encore TLS 1.2. Notez que le <rfc num="9325"
  local="false"/>, que notre RFC met à jour, ne donnait TLS 1.3 que
  comme « recommandé » (section 5).</p>
  <p>La plupart des <wikipedia name="Bibliothèque logicielle">bibliothèques</wikipedia> TLS
  permettent au programmeur d'imposer une version minimale de TLS donc
  respecter cette exigence « au moins 1.3 » ne devrait pas poser de
  problème (section 4).</p>
  <p>Le RFC note (section 3) qu'à l'heure actuelle, le monde de la
  cryptographie est occupé à préparer une transition vers des
  algorithmes <wikipedia name="Cryptographie
  post-quantique">post-quantiques</wikipedia> (<rfc num="9958" local="true"/>). Comme TLS
  1.2 est gelé (cf. <rfc num="9851" local="true"/>), les <link
  url="https://www.nist.gov/cybersecurity/what-post-quantum-cryptography">solutions
  post-quantiques</link> n'y seront pas intégrées et, si un CRQC
  (<foreign>Cryptographically Relevant Quantum Computer</foreign>)
  finit par apparaitre un jour, TLS 1.2 ne sera plus sûr.</p>
  <p>Notez enfin que cette exigence d'avoir la version 1.3 s'applique
  à TLS, mais pas à <wikipedia name="Datagram Transport Layer
  Security">DTLS</wikipedia>.</p>
</content>
</rfcdesc>
