Resumen

  • La RFC 9420 define cómo un conjunto de clientes autenticados de MLS avanza de una época a otra mediante Proposals y un Commit.
  • El avance acredita un estado de protocolo delimitado, no consenso humano, entrega completa, aceptación de la aplicación, autoridad local ni un resultado externo.

La frase «el grupo decidió» suele ocultar una cadena de acontecimientos que no son equivalentes. Puede referirse a un mensaje enviado, a una actualización recibida por un terminal, a una regla de software satisfecha, a una autorización interna o a una acción que ya modificó el mundo exterior. Cada una requiere una fuente de evidencia distinta. El peligro comienza cuando el rastro más exacto —el criptográfico— absorbe sin examen el significado de todos los demás.

Messaging Layer Security aborda un problema delimitado: el establecimiento continuo de claves autenticadas para grupos de clientes. Para la RFC 9420, un grupo es una colección lógica de clientes que comparte un secreto común. Su historia forma una secuencia lineal de épocas. En cada época, un conjunto específico de clientes autenticados comparte estado criptográfico.

No es un detalle menor que el estándar hable de clientes. Un cliente se define por las claves que posee. No se define como una persona, una oficina, una sociedad mercantil ni una fuente de autoridad. La autenticación puede establecer, dentro del servicio de autenticación usado, que cierta clave corresponde al participante admitido por esa política. No demuestra que una persona haya visto una Proposal, que represente a quien debe decidir o que tenga permiso para comprometer recursos ajenos.

La mecánica del cambio está bien especificada. Una Proposal plantea una modificación —por ejemplo, añadir, actualizar o retirar un miembro—. Un Commit implementa las modificaciones contenidas en un conjunto de Proposals. Al crear o procesar un Commit, un cliente mueve el árbol de ratchets y el GroupContext del estado anterior al que abre la época nueva. El contexto reúne, entre otros elementos, el identificador del grupo, la época, el hash del árbol y el hash confirmado del transcript. Si se añaden clientes, se genera a la vez el Welcome correspondiente para que puedan establecer su copia del estado resultante.

Eso permite afirmar algo serio: se procesó una transición MLS definida conforme a las validaciones del protocolo. Los mecanismos de transcript y confirmación vinculan material del protocolo a través de las épocas. La estructura también protege secretos de grupo bajo las condiciones que especifica la RFC. Pero el nombre Commit no convierte esa transición en acta de una reunión. No es una votación, un contrato, un permiso de gasto ni la prueba de que un cambio operacional se realizó. Es el mensaje que incorpora Proposals y hace avanzar estado criptográfico.

El modelo de entrega explica por qué esa delimitación importa. MLS supone un Authentication Service de confianza para validar credenciales y un Delivery Service que enruta mensajes pero se considera en gran medida no confiable. Un servicio de entrega comprometido no puede falsificar mensajes MLS válidos. Sin embargo, puede retrasarlos o eliminarlos selectivamente, bloquear de forma permanente mensajes de un miembro e incluso influir en cuál Commit se aplica cuando la aplicación usa el servicio para resolver conflictos entre Commits simultáneos.

Por eso, un Commit válido no es recibo de circulación completa. Puede confirmar una transición de estado sin demostrar que todos los clientes relevantes recibieron la información oportunamente. Salvo el valor de generación de datos del remitente, la RFC deja a la aplicación la detección de pérdidas. Quien necesite demostrar entrega, plazo o cobertura debe registrar esos hechos en la capa de entrega y no deducirlos de que nadie logró falsificar una firma.

La RFC también deja fuera, de manera explícita, el acuse de procesamiento que algunas aplicaciones necesitan. Describe un caso en que los miembros capaces de detectar un Commit malformado están desconectados; el estado que resulta puede servir de base para Commits posteriores y, al volver, esos miembros pueden no poder ponerse al día. La aplicación puede requerir acuses de procesamiento correcto antes de tratar el Commit como aceptado. MLS no incorpora por sí mismo ese mecanismo de acuse.

Ahí se separan cuatro hechos que una interfaz no debería fundir: existe un Commit; la aplicación lo considera aceptado; se reunió el conjunto de acuses que esa aplicación exige; y una entidad autorizada decidió que correspondía una acción. El protocolo gobierna el primero. La aplicación posee la regla del segundo y tercero. La institución responsable conserva la autoridad del cuarto. Ningún hash transforma el resultado de una capa en la decisión de otra.

Un diseño honesto mantiene un registro por capas: grupo y época MLS; Commit y Proposals asociados; contexto de credenciales; observaciones de entrega; regla, umbral y plazos de acuse; decisión local; acción finalmente ejecutada. Entonces una revisión posterior puede preguntar sin ambigüedad qué cambió en el protocolo, qué terminales lo procesaron, qué aceptó la aplicación y qué produjo efectos fuera de ella.

La distinción de Lu Heng entre representación, decisión local y resultado ejecutado sirve aquí como disciplina. La época MLS es una representación técnica fuerte y verificable. Confiar en ella significa no forzarla a representar también el consentimiento, la autoridad o el efecto que pertenecen a otros sistemas.

Sources