Résumé

  • La révision 19 de Roughtime décrit un protocole expérimental : des échanges signés et enchaînés permettent d’établir qu’au moins un serveur a donné une heure incompatible avec l’ordre causal. La démonstration ne suffit pas toujours à identifier lequel.
  • Le projet fournit un format de liste de serveurs et un format de rapport, tout en laissant hors de son périmètre l’acceptation des preuves, l’instruction, la mise à l’écart et l’entretien des listes. Ces fonctions sont pourtant qualifiées d’essentielles à la sécurité.
  • Un reçu d’exclusion portable devrait relier le condensat du rapport, les limites d’attribution, l’examinateur habilité, la décision, les anciennes et nouvelles listes signées, leur distribution, leur adoption et la voie de rectification. C’est une proposition de Daniel Kade, pas une règle de l’IETF.

La signature authentifie une voix, pas l’heure

Un équipement longtemps éteint peut ne plus savoir quelle heure il est. Or la validation d’un certificat exige déjà un repère temporel raisonnable. Roughtime s’attaque à ce cercle : fournir un intervalle horaire authentifié à un client presque sans horloge et lui permettre de conserver une preuve extérieure lorsque plusieurs sources de confiance se contredisent.

Le texte actuel est draft-ietf-ntp-roughtime-19, publié le 17 mars 2026 pour le statut Experimental. L’IESG l’a approuvé le même jour. Le Datatracker l’indique aujourd’hui dans la file de l’RFC Editor et, depuis le 4 septembre, en seconde passe éditoriale. Ce chemin ne doit pas être confondu avec son terme : la révision 19 demeure un Internet-Draft tant que l’édition n’a pas abouti.

Le premier échange est volontairement sobre. Le client envoie un nonce imprévisible. Le serveur répond avec un milieu, un rayon d’incertitude et une signature reliée à la requête par un engagement de type arbre de Merkle. On peut alors vérifier que la clé annoncée a produit cette réponse après réception du nonce.

Rien dans cette vérification ne transforme une mauvaise horloge en bonne horloge. Une clé intacte peut signer un intervalle faux à cause d’une panne, d’une compromission, d’une source amont défectueuse ou d’un acte volontaire. L’apport singulier de Roughtime apparaît avec plusieurs serveurs : un élément de la réponse précédente entre dans la requête suivante, ce qui lie les observations à leur ordre réel.

Lorsque les intervalles signés ne peuvent pas respecter cet ordre, la contradiction devient transportable. Les octets de requête et de réponse, les clés et l’aléa permettent à un autre vérificateur de refaire les contrôles. La conclusion exacte reste toutefois « au moins une réponse est fausse ». Selon la forme de la chaîne, la cryptographie peut ne pas révéler laquelle.

Il faut donc séparer trois énoncés : cette clé a signé cette réponse ; ces réponses ne peuvent pas toutes être vraies ; cette clé précise doit sortir de la liste. Seuls les deux premiers peuvent parfois provenir directement du protocole.

Le protocole reconnaît la frontière de jugement

Le projet n’essaie pas de cacher le manque institutionnel. Il explique qu’une expérience d’exploitation est nécessaire pour entretenir un écosystème, distribuer des listes de serveurs de confiance et traiter les rapports. Il borne son travail au protocole sur le fil et aux formats utiles. Les moyens de tenir la liste, les politiques à lui appliquer et le mécanisme d’examen ne sont pas définis.

Cette retenue est saine. Une preuve peut être déterministe ; un jugement doit combiner des règles de validation, des limites d’attribution, des sources complémentaires, des conflits d’intérêts et des conséquences opérationnelles. Ajouter au paquet un bit « coupable » ne ferait que déplacer une décision humaine ou organisationnelle dans un champ opaque.

Le nom anglais malfeasance report risque d’ailleurs d’aller plus loin que l’évidence. Il évoque une faute intentionnelle. La contradiction peut provenir d’une erreur de configuration, d’une compromission de clé, d’une horloge amont trompée ou d’un défaut logiciel. Le premier état public défendable n’est pas « coupable », mais contradiction vérifiée, attribution en cours.

Le projet précise aussi qu’un échec de signature ou une autre erreur de protocole ne doit pas, à lui seul, déclencher ce type de rapport. Le rapport correspond à une sémantique déterminée : l’incompatibilité causale d’une suite de réponses autrement exploitable. Préserver cette frontière empêche qu’un même canal mélange preuve temporelle, bruit réseau et alarmes d’implémentation.

La liste est un programme de confiance

Les clés publiques durables des serveurs sont les racines de confiance de Roughtime. Le client a besoin d’au moins trois serveurs opérationnels sous des exploitations indépendantes. Il devrait mettre à jour sa vision des serveurs fiables pour tirer parti des fautes détectées.

Le format JSON commun peut contenir nom, adresse, versions et clé publique, ainsi que des listes sources et une URL HTTPS pour envoyer les rapports. Son usage est facultatif : une implémentation peut configurer autrement ses sources.

Cette faculté protège un principe important. Le standard rend la liste portable sans désigner un conservateur mondial. Un système d’exploitation, une entreprise ou un collectif de recherche peut publier son propre ensemble. Deux parcs peuvent adopter des décisions différentes sans que l’un devienne illégitime aux yeux du protocole.

Mais tenir une liste n’est pas une tâche neutre. Ajouter une clé lui donne une place dans la construction de la preuve. La retirer prive les clients adoptants d’une source future. Attendre trop longtemps prolonge l’exposition ; agir trop vite peut réduire la diversité au point d’affaiblir la mesure. Une restauration silencieuse peut effacer l’histoire de la décision.

Le gestionnaire exerce donc un pouvoir délégué et borné. Il ne punit pas un serveur au nom d’une souveraineté Internet. Il propose un nouvel état de confiance à ceux qui ont choisi de suivre sa liste. La réalité change seulement lorsque le logiciel reçoit, authentifie et accepte cet état.

Du rapport reçu au rapport conservé

Lorsqu’une contradiction est détectée, le client devrait produire un rapport si cela est techniquement possible, prévenir l’utilisateur et refaire une mesure. Si la liste fournit une destination, l’envoi se fait par POST sur HTTPS.

Une panne d’un serveur populaire peut provoquer un afflux massif. Le projet impose donc un recul exponentiel et recommande des intervalles bornés. Cette protection de disponibilité ne doit pas devenir une politique de disparition de la preuve.

Le récepteur devrait calculer l’identité de contenu du rapport, en accuser la garde durable puis distinguer doublons exacts et chaînes distinctes. Compter chaque réessai comme une nouvelle affaire fabriquerait un consensus artificiel ; fusionner toutes les observations d’une même clé cacherait au contraire l’étendue et la topologie de la panne. Le reçu de dépôt doit dire « conservé » ou « déjà présent », jamais « exclusion prononcée ».

La confidentialité mérite une discipline comparable. Les données nécessaires à la vérification doivent rester intactes, mais l’adresse du terminal ou son identité administrative ne devraient être conservées que si elles apportent réellement quelque chose à l’analyse. La portabilité de la preuve ne justifie pas la création d’un registre des clients.

Attribuer sans transformer une hypothèse en verdict

Une chaîne peut montrer un serveur isolé entre deux témoins cohérents. Elle peut aussi n’offrir que deux affirmations incompatibles, ou regrouper plusieurs machines dépendant de la même source de temps. La liste du client peut être ancienne. Une clé peut avoir été volée. Le serveur minoritaire peut être le seul juste face à plusieurs sources corrélées.

L’examen doit donc rejouer chaque signature, chaque nonce et chaque intervalle, contrôler le traitement du rayon et des secondes intercalaires, puis déclarer la force de l’attribution. Trois résultats sont honnêtes : clé identifiée, ensemble de clés candidates, contradiction non attribuée.

Des éléments extérieurs peuvent affiner le résultat : télémétrie de l’opérateur, registres de garde des clés, observations de sources indépendantes. Ils doivent être nommés comme tels. Une déduction opérationnelle n’acquiert pas la qualité d’une preuve cryptographique par simple juxtaposition.

Révoquer définitivement dès la première contradiction privilégierait la vitesse au prix d’une fausse certitude. N’agir qu’avec une certitude absolue rendrait la preuve inopérante. Une réponse graduée est plus robuste : réduire temporairement le poids ou mettre en quarantaine, instruire, publier l’incertitude, puis retirer, restaurer ou maintenir sous une échéance explicite.

NTS et Khronos éclairent d’autres limites

La RFC 8915 définit Network Time Security. TLS sert à l’établissement des clés et l’AEAD protège les échanges NTP. Le client peut vérifier l’origine et l’intégrité des paquets selon le modèle de NTS, mais un serveur authentifié peut toujours posséder une heure fausse.

Roughtime peut aider un terminal dépourvu d’heure fiable à atteindre l’intervalle nécessaire pour valider le certificat NTS. Il ajoute aussi une preuve extérieure des contradictions. Les deux mécanismes sont complémentaires, non concurrents.

Khronos, dans la RFC 9523, renforce la sélection et le filtrage des sources NTP contre des attaquants qui déplacent l’heure. Il protège le choix local. Roughtime insiste sur une contradiction démontrable à un tiers. Or une bonne sélection n’écrit pas automatiquement un dossier d’imputation, et un bon dossier ne choisit pas automatiquement la prochaine liste.

Les RFC 8633 et 7384 rappellent la nécessité de plusieurs sources, de la surveillance et d’un modèle de menace pour les horloges. Elles confirment la portée stratégique du temps, pas l’existence d’une autorité universelle capable de sortir une clé.

Un reçu d’exclusion portable

Pour relier ces limites sans créer de tribunal central, Daniel Kade propose un reçu d’exclusion portable. Il ne modifie pas le protocole. Il documente les transitions institutionnelles autour de la preuve.

La première partie fixe le rapport : condensat, chaîne ordonnée complète, version du vérificateur, résultat de chaque signature et de chaque liaison, condensat exact de la liste source du client. Le contexte de collecte reste minimal.

La deuxième sépare attribution et décision. Elle indique si une clé est identifiée, seulement candidate ou toujours indéterminée. Elle nomme l’examinateur habilité, ses conflits d’intérêts, les preuves extérieures utilisées, le motif, la confiance et l’échéance de la mesure.

La troisième décrit l’action : quarantaine, pondération, retrait ou restauration. Elle relie cryptographiquement l’ancienne liste à la nouvelle par leurs condensats, leur séquence, le signataire et l’heure d’effet. Une mesure temporaire expire si elle n’est pas renouvelée sur un dossier explicite.

La quatrième prouve la diffusion sans inventer l’adoption. Elle enregistre les points de publication et l’archive de transparence, puis mesure de façon respectueuse de la vie privée les versions effectivement installées. Un parc local peut refuser ou bifurquer ; il assume alors son risque sans falsifier la décision du publieur.

Enfin, le reçu garde une voie de correction. L’opérateur du serveur peut montrer une compromission, réparer sa source, faire tourner sa clé ou contester l’attribution. Une restauration devient une nouvelle transition signée, non une réécriture silencieuse.

La confiance change au dernier kilomètre, dans le client. Tant que le nouveau condensat n’est pas reçu, vérifié et accepté, l’annonce de retrait n’a pas d’effet technique. Et une fois le retrait appliqué, le client doit encore disposer d’assez de serveurs indépendants pour ne pas transformer une précaution en panne de démarrage sécurisé.

Roughtime rend une contradiction difficile à nier. Une bonne gouvernance conserve ce gain sans prétendre que la preuve peut exercer, à elle seule, le jugement, la publication et l’adoption.

Sources