Résumé

  • La RFC 9420 définit une progression MLS, par Proposals et Commit, vers un nouvel epoch partagé entre des clients authentifiés.
  • Cette progression ne constitue pas une preuve de lecture, de consensus, d’autorisation, d’accusé de traitement applicatif ni d’effet métier.

Dans les organisations, le mot « accord » est souvent utilisé pour couvrir plusieurs événements incompatibles. Une personne a envoyé un message. Un terminal a reçu une mise à jour. Une application a accepté une opération. Un responsable a autorisé une action. Le système extérieur a finalement été modifié. Chacune de ces propositions demande ses propres preuves. Les condenser sous une même étiquette ne les fait pas devenir vraies ensemble.

Messaging Layer Security, ou MLS, résout une question plus étroite et importante : comment des clients peuvent maintenir un état cryptographique de groupe, de manière asynchrone, avec les propriétés de sécurité définies par le protocole. La RFC 9420 décrit un groupe comme une collection logique de clients partageant un secret commun. Son histoire est une séquence linéaire d’epochs. Dans chacun, un ensemble précis de clients authentifiés détient un état cryptographique partagé.

Le mot décisif est ici « client ». La RFC le définit par les clés cryptographiques qu’il détient. Elle ne le définit pas comme une personne, une fonction, une entreprise ou un titulaire de pouvoir. Un client peut être correctement authentifié dans le cadre du service d’authentification prévu par l’application sans établir que quelqu’un a compris une proposition, qu’il pouvait engager une institution ou qu’il a choisi d’approuver une mesure. Ces ne sont pas de petites nuances sémantiques : elles désignent des surfaces de contrôle différentes.

La transition MLS elle-même est concrète. Une Proposal suggère une modification du groupe — ajout, mise à jour, retrait ou autre action définie. Un Commit met en œuvre un ensemble de Proposals. Lors de la création ou du traitement d’un Commit, le client fait progresser l’arbre à cliquets et le GroupContext, de l’epoch précédent vers le suivant. Ce contexte inclut notamment l’identifiant du groupe, le numéro du nouvel epoch, un hash de l’arbre et un hash du transcript confirmé. Si des clients sont ajoutés, l’auteur du Commit construit le Welcome correspondant afin qu’ils puissent établir leur copie de l’état résultant.

Cette suite de faits permet une affirmation forte mais bornée : selon les règles MLS, un client a traité une transition d’état précise. Le transcript et la confirmation relient les éléments de protocole définis d’un epoch à l’autre. La cryptographie ne sert pas de décoration à un récit humain ; elle fournit de la cohérence et de l’intégrité à un état de groupe. Mais le Commit ne devient pas pour autant un procès-verbal. Le terme ne veut pas dire délibération, vote, délégation de pouvoir, signature de contrat ou réalisation d’un changement opérationnel. Il veut dire que le protocole a incorporé des Proposals et avancé son état.

Le modèle de livraison de la RFC empêche d’étendre cette preuve sans précaution. MLS suppose un Authentication Service auquel il fait confiance pour valider des identifiants, et un Delivery Service chargé de router les messages mais largement non fiable. Un Delivery Service compromis ne peut pas forger un message MLS valide. Il peut toutefois retarder ou supprimer sélectivement des messages, bloquer durablement le trafic d’un membre et, lorsque l’application lui laisse résoudre des Commits simultanés, influencer lequel sera appliqué.

Il faut donc distinguer « le Commit est valide » de « tous les destinataires pertinents l’ont reçu dans le délai nécessaire ». La RFC laisse à l’application la détection de pertes, à l’exception de l’indicateur de génération des données d’émetteur. Une application qui doit démontrer la circulation complète d’une instruction doit produire cette trace de livraison et ses délais. Elle ne peut pas déduire un accusé collectif du seul fait qu’aucune falsification cryptographique n’a été observée.

La RFC 9420 va plus loin pour les accusés de traitement. Dans une application asynchrone, les clients qui auraient pu reconnaître un Commit malformé peuvent être hors ligne. Un état résultant peut alors servir de base à d’autres Commits ; à leur retour, les clients affectés peuvent ne plus parvenir à rattraper le groupe. La RFC explique qu’une application peut exiger des accusés de traitement réussi avant de considérer un Commit comme accepté. Elle précise aussi que MLS ne fournit pas ce mécanisme en natif.

Cette séparation est une instruction de conception. L’existence d’un Commit, l’acceptation applicative d’un Commit, la collecte d’accusés suffisants et la décision de personnes autorisées sont quatre événements différents. Le protocole établit le premier dans son propre périmètre. L’application possède la règle des trois suivants lorsqu’ils relèvent de son opération. L’institution conserve l’autorité sur toute décision qui engage ses ressources, ses obligations ou ses effets externes.

Un registre de contrôle sérieux doit donc conserver les couches plutôt que les fusionner. Il doit distinguer l’identifiant et l’epoch MLS, le Commit et ses Proposals, le contexte de liaison des identifiants, les observations de livraison, la règle d’accusé et son seuil, la décision locale et l’action effectivement exécutée. Ce n’est qu’ainsi qu’une revue ultérieure peut répondre séparément : l’état cryptographique a-t-il changé ? quels clients l’ont-ils traité ? l’application l’a-t-elle accepté selon sa règle ? une autorité a-t-elle décidé, et un effet a-t-il suivi ?

La lecture de Lu Heng apporte ici une discipline éditoriale : une représentation exacte n’est ni la décision locale qui lui donne conséquence, ni le résultat qui s’exécute après elle. L’epoch MLS est une représentation technique particulièrement robuste. Le respecter, c’est lui refuser une autorité qu’il ne revendique pas.

Sources