Résumé

  • draft-mahy-mls-semiprivatemessage-07 chiffre un Commit ou une Proposal pour une liste convenue de récepteurs externes tout en liant leur vue à celle des membres.
  • Le récepteur récupère clé, nonce, garde anti-réutilisation et index de feuille par HPKE, mais la vérification de signature dépend encore d’une copie du GroupContext correspondant.
  • Déchiffrement, identité du contenu, état de l’époque, auteur authentifié, habilitation du récepteur et résultat opérationnel constituent donc des preuves différentes. La révision 07 reste provisoire et son analyse de sécurité est inachevée.

Le piège tient dans une scène très plausible. Un service de fédération reçoit un Commit MLS, trouve son entrée, ouvre l’enveloppe HPKE puis le ciphertext commun. Le bourrage est correct. Le hash de FramedContentTBS correspond. Son tableau de bord pourrait afficher « vérifié ».

Il n’a pourtant pas encore nécessairement vérifié la signature de l’émetteur.

La révision 07 de SemiPrivateMessage ne cache pas cette limite. Un récepteur externe ne sait pas déchiffrer encrypted_sender_data. Il reçoit donc sender_leaf_index avec le matériel de message enveloppé pour lui. Cet index indique où regarder dans la mémoire du groupe ; il n’emporte pas à lui seul credential, extensions et état de l’époque.

Une réduction d’exposition, pas une autorisation générale

RFC 9420 fournit à MLS des formats publics et privés. Dans un système fédéré, un service de distribution peut devoir lire les propositions et commits entre domaines, sans les rendre publics à tous. Le projet ajoute alors une liste external_receivers au GroupContext et un format mls_semiprivate_message réservé aux handshakes.

La liste est convenue par les membres pour l’époque courante. Le format doit être supporté puis exigé par le groupe. Une capability déclarée ne prouve donc ni la sélection collective, ni l'envoi, ni l'acceptation.

Pour chaque destinataire, l'émetteur enveloppe avec HPKE une clé de message, un nonce, un reuse_guard et l'index de feuille. Le contexte HPKE incorpore group ID, epoch et un hash de l'index et du nonce. Ces liens empêchent une transplantation triviale ; ils ne distribuent pas à eux seuls tout le GroupContext.

Le hash d’égalité ne signe pas l’identité

framed_content_tbs_hash empêche l’émetteur de donner discrètement un contenu de handshake différent aux membres et aux récepteurs externes. C’est une garantie importante et étroite.

Reçu technique Ce qu’il établit Ce qui reste à établir
Référence du récepteur trouvée Une entrée correspond au descripteur haché Le récepteur est encore admis à cette époque
Ouverture HPKE Sa clé privée ouvre le matériel de message L’identité MLS de l’émetteur
Ouverture AEAD Ciphertext et données authentifiées sont intègres La fraîcheur du GroupContext
Hash de contenu égal Les deux publics voient le même FramedContentTBS Le traitement ou l’acceptation
Signature MLS valide L’auteur correspond à l’état de groupe utilisé Le droit du service externe d’agir
Résultat aval Un traitement précis s’est produit La convergence de tous les membres

Le bon état intermédiaire est donc « déchiffré, contenu lié, authentification en attente ». Une absence de contexte n’est pas une mauvaise signature. Une bonne signature n’est pas une délégation institutionnelle.

Le GroupContext doit avoir une provenance

Un service peut conserver le contexte de l’époque N alors qu’un message annonce N+1. Il peut encore posséder une ancienne clé après son retrait de la liste. Le même numéro de feuille peut désormais porter un autre credential. Pour éviter qu’un cache périmé devienne autorité, le reçu doit conserver le digest exact du GroupContext, sa source, son heure d’acquisition et l’époque à laquelle il s’applique.

Il faut aussi enregistrer le descripteur externe et les digests de son credential et de sa clé ; l’autorité qui l’a admis ; le résultat HPKE ; l’index de feuille ; le résultat du hash de contenu ; l’état non exécutée/réussie/échouée de la signature ; le credential utilisé ; la décision locale ; et l’effet aval.

La liste visible est une surface de gouvernement

Le projet améliore la confidentialité par rapport à PublicMessage, mais précise que la liste des récepteurs reste visible dans GroupContext. Les membres savent donc qui reçoit ces handshakes. Cette visibilité rend contrôlable une question que la cryptographie ne tranche pas : qui peut ajouter un service, pour quelle durée et sous quelle règle ?

The Policy Mirror invite à conserver acteur, règle, périmètre et conséquence au moment où une liste technique devient une délégation. L’extension représente cette liste ; elle n’est pas le mandat qui l’a créée.

L’incertitude fait partie de l’état courant

La révision 07 est un Internet-Draft individuel. Ses valeurs IANA sont provisoires. Le registre MLS de l’IANA ne transforme pas une valeur TBD en assignation, et RFC 8126 n’atteste aucun déploiement.

Surtout, la section Security Considerations se termine encore par TODO More Security. Ce signal doit rester dans l'article : le mécanisme peut être expérimenté, mais son analyse de sécurité n'est pas achevée.

Sources