Résumé

  • La RFC 9662 maintient deux suites RSA dans le socle à implémenter pendant la migration, mais donne la préférence à TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 et distingue nettement les règles de version de TLS et de DTLS.
  • Une exception autorisant temporairement RSA/CBC doit avoir un périmètre, un responsable, une justification et une échéance ; son existence ne prouve pas que la suite a été négociée ni qu’une journalisation a abouti.
  • La preuve utile relie la politique et l’époque de connexion à l’identité de l’événement, à l’acceptation du collecteur, à l’écriture durable, à l’indexation et à une relecture contrôlée.

Le registre de dérogations était impeccable. Chaque équipement ancien avait un propriétaire, une raison et une date de retrait. Pourtant, lors d’une revue d’incident, personne ne pouvait établir si la dérogation avait réellement servi, quel chiffrement avait été négocié, ni si les messages produits pendant la fenêtre avaient atteint l’archive.

Cette lacune révèle la juste portée de la RFC 9662. Le texte met à jour les règles cryptographiques des transports syslog sur TLS et DTLS définis par les RFC 5425 et 6012. Il améliore le terrain d’entente entre implémentations sans prétendre observer une configuration locale, une connexion réelle ou le sort d’un message particulier.

Le choix est volontairement progressif. L’ancienne suite TLS_RSA_WITH_AES_128_CBC_SHA reste obligatoire à implémenter, tandis que TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 rejoint ce socle et doit être préférée. Un administrateur peut permettre l’ancienne suite si son interdiction couperait la livraison de syslog avant la mise à jour d’un appareil. Ce compromis protège la continuité. Il ne transforme pas la dérogation en état cible.

Trois registres, trois décisions

Le premier registre décrit la capacité. Il indique le logiciel ou micrologiciel, les versions TLS ou DTLS et les suites que l’équipement sait implémenter. « Obligatoire à implémenter » appartient à ce niveau. Il garantit un vocabulaire technique commun ; il n’ordonne pas d’activer toutes les options sur chaque interface.

Le deuxième registre décrit la politique. Il contient les suites activées, leur ordre de préférence, les pairs autorisés, la révision de configuration et les exceptions. Une capacité peut être désactivée. Une ancienne option peut être tolérée pour un groupe précis, pendant une durée précise. Confondre capacité et politique rend impossible de savoir si un écart vient du produit ou d’une décision locale.

Le troisième registre décrit l’exécution. Il observe, pour chaque époque de connexion, la version et la suite effectivement négociées, la validation du certificat, la reprise de session et l’usage éventuel de données précoces. Ce registre ne peut pas être reconstruit honnêtement à partir d’une capture d’écran de configuration. Une préférence n’est pertinente que si les deux pairs peuvent la sélectionner.

Il faut enfin un quatrième ensemble de preuves, centré sur les messages. La négociation d’un canal ne dit pas quel événement y est entré. Une dérogation peut n’avoir jamais été utilisée ; à l’inverse, elle peut être sélectionnée chaque heure par une branche de parc oubliée. C’est l’observation qui tranche.

TLS et DTLS ne partagent pas la même phrase de transition

Pour le transport TLS de syslog, TLS 1.2 reste obligatoire à implémenter. TLS 1.3 devrait être pris en charge et doit être préféré lorsqu’il est disponible. Cette règle fixe un plancher et une direction, sans affirmer que toutes les sessions du parc utilisent déjà TLS 1.3.

Pour le transport DTLS, la rupture est plus franche : DTLS 1.0 ne doit pas être utilisé ; DTLS 1.2 doit l’être. DTLS 1.3 devrait être pris en charge et préféré lorsqu’il est implémenté. La RFC 8996 et les recommandations de la RFC 9325 expliquent le contexte de sécurité de cette évolution.

Une preuve qui ne nomme que « 1.2 » est donc incomplète. TLS 1.2 et DTLS 1.2 n’offrent pas les mêmes propriétés de transport. Un datagramme protégé n’acquiert pas un accusé de réception applicatif. Une connexion TLS durable ne prouve pas que la file source, le collecteur et l’index sont restés sains.

Les textes de TLS 1.3 et DTLS 1.3 modernisent à leur tour le transport cryptographique. Ils ne créent pas une sémantique de livraison de bout en bout que syslog ne possède pas.

Une dérogation doit conserver son motif opérationnel

Le risque le plus visible est une exception sans échéance. Le risque moins visible est l’inverse : retirer la seule suite commune avant la mise à jour d’un appareil et perdre sa télémétrie. Une posture cryptographique paraît alors meilleure au moment même où l’organisation devient aveugle.

La bonne unité de décision n’est donc pas « ancien chiffrement autorisé : oui ou non ». Il faut nommer la classe d’équipements, la version, le collecteur, le pair, la suite, la raison de continuité, les mesures compensatoires, le responsable, l’approbation, l’expiration et le test de migration. Il faut surtout mesurer l’usage réel de l’exception.

Le registre TLS de l’IANA coordonne les identifiants et certains statuts. Il n’observe ni la configuration d’un terminal ni une négociation vivante. Le statut du registre, le code livré, la politique activée et le résultat de connexion sont quatre couches de réalité distinctes.

Interdire les données précoces ne crée pas une livraison exacte

La RFC 9662 interdit les données précoces de TLS 1.3 pour ce profil. Le protocole syslog ne fournit pas de protection contre la répétition ; les propriétés plus faibles du mode précoce rendraient ambigu un événement rejoué. Cette interdiction ferme une voie précise.

Elle ne garantit pas qu’un message envoyé après la poignée de main soit livré une seule fois. Un événement peut être dupliqué avant chiffrement, rester dans une file, disparaître lors d’une reconnexion, être perdu en datagramme, refusé par le collecteur, dirigé vers le mauvais locataire, supprimé trop tôt ou rendu introuvable par l’index.

Il faut donc tester séparément deux affirmations. D’une part, aucune donnée syslog ne doit passer comme donnée précoce. D’autre part, un événement témoin postérieur à la négociation doit être créé, expédié, accepté, écrit durablement, indexé et relu. Réussir le premier test ne répond pas au second.

Le certificat authentifie un pair, pas la rétention

La validation de certificat s’appuie notamment sur le cadre de la RFC 5280. Une chaîne valide peut toutefois aboutir à une ancre inattendue, porter une identité de service inadéquate ou authentifier un pair que la politique locale n’autorise pas. Ces contrôles doivent rester explicites.

Même correctement authentifié, le canal s’arrête avant la preuve de conservation. Chaque événement témoin a besoin d’un identifiant stable et respectueux de la confidentialité, de son heure de création, de son passage en file, de l’époque de connexion, du résultat d’envoi, d’un identifiant d’acceptation, du résultat d’écriture, de la destination d’index, de la classe de rétention et d’une relecture ultérieure.

Les échecs doivent rester nommés : absence de suite commune, version interdite, échec de chaîne ou d’identité, pair non autorisé, donnée précoce refusée, rupture de connexion, débordement de file, perte de datagramme, rejet du collecteur, échec de stockage ou résultat absent à la recherche. Une seule alerte « syslog sécurisé en échec » ne permet pas d’attribuer la garde.

Reconstituer la preuve depuis la recherche

Commencer par le résultat attendu évite de surévaluer le contrôle le plus facile à montrer. Un enquêteur autorisé peut-il retrouver l’événement dans la fenêtre de rétention promise ? Si oui, il faut relier ce résultat à l’objet durable et à l’acceptation du collecteur, puis à l’envoi, à l’époque de connexion, à la file source, au pair validé et à la révision de politique. L’exception rejoint la chaîne par son responsable et son expiration.

La doctrine de Heng Lu éclaire cette proportion. Minimum Initial Specification défend un plancher commun réduit et explicite, en laissant les choix locaux visibles. Reality Layers empêche l’étiquette normative d’emprunter l’autorité d’un résultat d’exploitation. Running-Code Primacy place la preuve décisive dans la connexion et le message effectivement traités.

La RFC 9662 améliore le socle partagé sans nier la durée des migrations. Une direction doit préserver cette nuance : l’exception cryptographique protège parfois la continuité, mais seule une chaîne par événement prouve que cette continuité a produit une trace exploitable.

Sources