Résumé

  • RFC 3436 associait deux flux SCTP de sens opposés portant le même identifiant, puis établissait une connexion TLS distincte sur chaque paire ; la reprise de session réduisait le travail sans supprimer ce périmètre par connexion.
  • Un flux TLS perdait la livraison non ordonnée et la durée de vie limitée, tandis que les chunks de contrôle SCTP restaient hors de la protection des données utilisateur. RFC 6083 déplaça ensuite la frontière vers une connexion DTLS par association.

Plusieurs états sous un même toit

Une association SCTP peut être active alors qu’un de ses flux a terminé un handshake complet, qu’un autre reprend une session, qu’un troisième attend son premier usage et qu’un quatrième transporte des données SCTP sans TLS. Dire « l’association est sous TLS » transforme cette diversité en statut fictif.

Publié en décembre 2002, RFC 3436 adapta TLS 1.0 à SCTP. Le texte, la notice RFC Editor, la fiche IETF et son historique prouvent la règle publiée, pas une mise en œuvre, une interopérabilité ni un bénéfice de production.

TLS 1.0 supposait un flot d’octets fiable et ordonné. SCTP proposait des messages délimités, plusieurs flux et le multihoming. Sans modifier l’un ou l’autre protocole, RFC 3436 plaça un enregistrement TLS dans un message utilisateur SCTP. SCTP devait fragmenter et réassembler ce message afin de cacher le MTU à TLS et d’éviter la fragmentation IP. La taille minimale exigée atteignait 18 437 octets, 2^14 + 2048 + 5.

L’indépendance se payait en handshakes

Les flux de même numéro, dans les deux sens, formaient une paire bidirectionnelle. Le nombre de paires était le plus petit des deux nombres de flux négociés ; les flux restants demeuraient unidirectionnels et ne pouvaient pas porter TLS selon ce schéma.

Chaque paire protégée obtenait sa connexion et son handshake. Elle pouvait réaliser un échange complet, reprendre une session issue d’une autre connexion, ou attendre son premier usage. La reprise économisait du calcul ; des handshakes complets parallèles pouvaient mieux convenir à un chemin à forte latence. Mais une session partagée ne rendait pas les connexions interchangeables : chaque flux devait terminer son propre échange avant d’envoyer des données protégées.

Cette granularité empêchait le blocage d’un flux de suspendre tous les autres. Elle multipliait aussi états cryptographiques et messages lorsque le nombre de flux augmentait.

La protection amputait les propriétés du transport

TLS exigeait l’ordre strict de ses enregistrements. RFC 3436 interdisait donc la livraison non ordonnée et la durée de vie limitée sur les flux TLS. Un enregistrement devenu inutile ne pouvait pas simplement être abandonné. RFC 3758 introduisit ensuite la fiabilité partielle, sans pouvoir la faire entrer dans ce flux TLS sériel.

La limite la plus importante concernait le plan de contrôle. RFC 4895 rappela que TLS selon RFC 3436 ne protégeait que les données utilisateur SCTP. L’authenticité des chunks nécessitait SCTP-AUTH. La confidentialité du contenu, l’identité TLS, l’authentification d’un chunk DATA et celle d’un chunk de contrôle étaient quatre reçus différents.

Le multihoming n’était pas davantage une identité. Un enregistrement pouvait arriver d’une adresse différente de celle observée au départ ; les décisions de sécurité devaient reposer sur le pair authentifié, non sur son adresse de transport.

DTLS changea le dessin

RFC 6083 qualifia ensuite de sérieuses quatre limites : absence de désordre, absence de fiabilité partielle, égalité nécessaire des nombres de flux et une connexion TLS par paire, coûteuse à grande échelle. Il plaça une connexion DTLS dans l’association. Les messages de sécurité passaient par le flux 0, ordonné et pleinement fiable ; les données applicatives pouvaient employer de nombreux autres flux, l’ordre libre et la fiabilité partielle. DATA et, le cas échéant, FORWARD-TSN devaient aussi être authentifiés par SCTP-AUTH.

RFC 8996 a depuis déprécié TLS 1.0 et 1.1 : les choix cryptographiques de 2002 sont historiques, pas prescriptifs aujourd’hui.

Les couches de réalité décrites par Heng Lu invitent à ne pas confondre publication, handshake, chunk authentifié et résultat applicatif. La primauté du code exécuté exige les mesures que le RFC ne fournit pas ; la spécification initiale minimale éclaire rétrospectivement ce choix de réutiliser deux protocoles au prix d’un profil étroit.

La phrase honnête n’était donc pas « SCTP est sécurisé », mais « ce flux a terminé cette connexion, avec cette identité et ces règles ; le contrôle de l’association exige encore sa propre preuve ».

Sources

Autres pièces figées