Resumen

  • La revisión 19 de Roughtime propone un protocolo Experimental donde una cadena de intercambios firmados puede demostrar que al menos un servidor dio una hora incompatible con el orden causal. La misma cadena no siempre identifica cuál fue.
  • El borrador define formatos para listas de servidores confiables e informes de mala conducta. Deja fuera el mantenimiento de las listas, la aceptación de informes, la adjudicación y el proceso de exclusión, aunque reconoce que son esenciales para la seguridad.
  • Un recibo portátil de exclusión debería unir la prueba exacta, el límite de atribución, la revisión autorizada, la decisión, la transición entre listas firmadas, su distribución, la adopción del cliente y la corrección. Es una propuesta editorial de Daniel Kade, no una norma del IETF.

Una respuesta auténtica todavía puede dar una hora falsa

La seguridad temporal arranca con una dependencia circular. Un equipo que vuelve después de meses sin energía quizá no conozca la fecha suficiente para validar certificados. Pero obtener tiempo seguro puede exigir primero validar el certificado del servicio que establecerá las claves. Roughtime ofrece una estimación aproximada autenticada y, sobre todo, una forma de conservar evidencia externa cuando las fuentes elegidas se contradicen.

draft-ietf-ntp-roughtime-19 se publicó el 17 de marzo de 2026 con destino Experimental. La IESG lo aprobó ese mismo día. Hoy el Datatracker lo sitúa en la cola del RFC Editor y muestra desde el 4 de septiembre el estado In Progress (Second Edit). Aun así, esta revisión sigue siendo un Internet-Draft hasta que termine la publicación; no debe presentarse como un RFC ya numerado.

En una consulta básica, el cliente crea un nonce. El servidor responde con un punto medio y un radio que delimitan el intervalo donde afirma que está la hora real. Una firma cubre un compromiso de árbol de Merkle ligado al nonce. El resultado demuestra que la clave de larga duración produjo la respuesta después de recibir esa solicitud.

La firma no certifica la calidad del reloj. Un servidor correctamente autenticado puede estar mal configurado, comprometido o depender de una fuente defectuosa. Por eso Roughtime encadena consultas a varios servidores: material de una respuesta pasa a la solicitud siguiente, fijando una relación que los intervalos posteriores no deberían violar.

Si las respuestas no pueden coexistir en ese orden, el cliente conserva solicitudes, respuestas, claves y aleatoriedad suficientes para que un tercero repita la comprobación. Lo demostrado es importante pero limitado: al menos un servidor dio una hora incorrecta. En ciertos conjuntos no hay base matemática para escoger al culpable único.

La primera disciplina de gobernanza es no saltar de “esta clave firmó” y “estas afirmaciones se contradicen” a “esta clave debe ser expulsada”. La tercera frase requiere otro tipo de autoridad.

El propio borrador separa prueba y juicio

La revisión 19 dice que la experiencia operativa deberá cubrir servicios capaces de mantener y distribuir listas confiables y de procesar informes. Especifica el protocolo en el cable y los formatos de intercambio, pero no las políticas de lista ni el mecanismo de revisión y exclusión.

También afirma que un proceso adicional es necesario para que un informe termine en una exclusión, y que las reglas operativas para aceptar o rechazar un caso quedan fuera del documento. Las consideraciones de seguridad califican de esenciales tanto el mantenimiento de listas como la adjudicación de infracciones.

No es un vacío que la criptografía pueda rellenar sola. Verificar bits puede ser determinista; atribuir una causa exige examinar el conjunto de servidores, dependencias comunes, custodia de claves, entradas de reloj y evidencia operacional. Aplicar una consecuencia añade preguntas de proporcionalidad, duración, revisión y continuidad del servicio.

La etiqueta malfeasance tampoco debe usarse como atajo hacia la intención. Una incoherencia puede revelar error, compromiso, defecto del software o manipulación deliberada. El estado inicial correcto es contradicción verificada, atribución pendiente. Eso protege el valor de la prueba sin hacerla decir más de lo que contiene.

La lista decide a quién se escucha

Las claves públicas persistentes son raíces de confianza para Roughtime. El borrador pide al menos tres servidores operativos que no estén bajo las mismas partes y aconseja actualizar la visión del cliente sobre cuáles siguen siendo confiables.

El formato JSON común puede incluir identidad, direcciones, versiones y clave, además de fuentes de otras listas y una URL HTTPS para recibir informes. Su adopción es opcional. Un cliente puede emplear otro mecanismo.

Esa opción impide confundir interoperabilidad con monopolio. El sistema operativo puede seleccionar una lista; una empresa puede mantener otra; un laboratorio puede publicar una tercera. La especificación no convierte a ninguna en registro mundial ni vuelve inválido al cliente que decide bifurcarse.

No obstante, editar una lista sí asigna consecuencias. Añadir una clave abre la puerta a sus intervalos firmados. Retirarla reduce el conjunto de fuentes de quienes adoptan la revisión. Una retirada precipitada puede destruir diversidad; una tardía mantiene exposición. Una restauración sin historia puede borrar el motivo del episodio.

El editor de listas ejerce una delegación concreta de sus usuarios. No ejerce jurisdicción sobre el servidor. Su resolución solo se vuelve realidad cuando existe una nueva lista autenticada y cada entorno decide instalarla.

La sobrecarga no debe borrar el expediente

Al detectar una contradicción, el cliente debería generar un informe si puede, avisar al usuario y repetir la medición. Si la lista contiene un destino, puede enviar el informe por HTTPS.

La caída de una fuente popular produciría miles de avisos simultáneos. El borrador exige retroceso exponencial y límites de reintento. Esa regla protege la disponibilidad del receptor, pero no autoriza a perder la única copia del caso.

Un receptor responsable identifica el contenido por hash, confirma custodia duradera y agrupa duplicados exactos sin mezclar cadenas distintas. Los reintentos no son nuevos votos; las rutas diferentes tampoco son el mismo incidente solo porque comparten una clave. La respuesta a la entrega debe decir “almacenado” o “ya recibido”, no “servidor revocado”.

El formato también permite minimizar datos personales. Para verificar la secuencia hacen falta los mensajes y claves, no necesariamente la identidad estable del equipo que observó el fallo. Una infraestructura de rendición de cuentas no debería convertirse en un censo de clientes.

La atribución necesita declarar su incertidumbre

Hay cadenas donde dos testigos coherentes aíslan una respuesta imposible. Otras contienen únicamente dos intervalos incompatibles. Varios servidores pueden compartir operador, referencia ascendente o fallo de software. Una clave puede ser robada. Incluso el único valor discrepante podría ser correcto si las demás fuentes están correlacionadas.

La revisión debe comprobar firmas, enlaces entre nonces, márgenes de radio, segundos intercalares e integridad de la captura. Después debe elegir una de tres salidas honestas: clave identificada, conjunto de candidatas o contradicción sin atribución.

La telemetría del operador o una referencia temporal independiente puede cambiar la conclusión, pero tiene una procedencia diferente. El expediente debe mostrar qué parte está probada por Roughtime y cuál es una inferencia sustentada por datos externos.

Una expulsión permanente automática ante el primer informe válido confunde velocidad con certeza. Exigir certeza absoluta para cualquier cautela convierte la evidencia en adorno. Entre ambos extremos cabe una cuarentena temporal, reducción de peso, investigación pública y decisión con caducidad.

Autenticación, selección y rendición de cuentas no son equivalentes

NTS, en RFC 8915, usa TLS y cifrado autenticado para proteger intercambios NTP. Permite confirmar que el paquete procede del servidor escogido y que no fue modificado o reproducido según su modelo. No garantiza que el reloj auténtico sea correcto.

Roughtime puede facilitar la estimación inicial necesaria para validar el certificado de NTS, y conserva evidencia contra fuentes firmadas incoherentes. Khronos, definido en RFC 9523, endurece la selección y filtrado del cliente frente a desplazamientos maliciosos de la hora. Una selección resistente protege al cliente; una prueba portable habilita examen por terceros. Son superficies distintas.

RFC 8633 recomienda diversidad, supervisión e investigación de desacuerdos. RFC 7384 detalla amenazas contra protocolos de tiempo y dependencias de certificados. Este contexto refuerza la necesidad operativa, no crea un juez criptográfico.

El recibo portátil de exclusión

Daniel Kade propone documentar el puente mediante un recibo portátil de exclusión. No es un mensaje nuevo del protocolo ni un tribunal universal. Es una cadena comprobable de decisiones locales.

Primero fija la evidencia: hash del informe, secuencia completa, versión del verificador, resultado de cada firma y enlace causal, y hash exacto de la lista usada por el cliente. El contexto del dispositivo se reduce a lo estrictamente necesario.

Luego registra la atribución. Declara si una clave está identificada, forma parte de un conjunto o no puede distinguirse. Nombra al revisor autorizado, expone conflictos, separa evidencia externa y da motivo, confianza, duración y condición de reevaluación.

La acción queda aparte: cuarentena, reducción de peso, retirada o restitución. Los hashes de la lista anterior y posterior, su número de secuencia, firma y entrada en vigor impiden una reescritura silenciosa. Toda medida temporal caduca salvo renovación explícita.

La distribución se prueba sin fingir adopción. El recibo señala puntos de publicación y archivo, mientras la flota comunica de forma agregada qué hash instaló, con qué retraso y por qué rechazó una versión. Una red con política propia puede tomar otra decisión y dejarla documentada.

Finalmente conserva la apelación. El operador puede demostrar un compromiso de clave, reparar la referencia temporal, rotar identidad o cuestionar la inferencia. Una corrección no borra el informe: añade una transición nueva y firmada.

La confianza cambia dentro del cliente. Un comunicado no actualiza cachés, verifica firmas ni supera configuraciones fijadas. Tampoco basta con instalar la nueva lista: después de retirar una fuente deben quedar al menos tres operadores independientes para que la defensa no inutilice el arranque.

La contribución de Roughtime consiste en hacer difícil negar una contradicción concreta. La contribución de una buena gobernanza consiste en hacer visibles y reversibles las decisiones posteriores, sin apropiarse de la prueba como licencia para gobernar a todos.

Fuentes