Resumo

  • A revisão 19 do Roughtime descreve um protocolo com destino Experimental no qual respostas assinadas e encadeadas podem provar que pelo menos um servidor informou um horário incompatível com a ordem causal. Nem toda cadeia identifica qual servidor errou.
  • O rascunho especifica formatos de lista de servidores confiáveis e de relatório de conduta indevida, mas deixa fora do escopo a aceitação, a adjudicação, a exclusão e a manutenção das listas. O próprio texto considera esses procedimentos essenciais à segurança.
  • Um recibo portátil de exclusão de confiança deveria ligar o hash do relatório, os limites da atribuição, a revisão autorizada, a decisão, a transição entre listas assinadas, a distribuição, a adoção e a correção. É uma proposta de Daniel Kade, não uma exigência da IETF.

A assinatura confirma a resposta, não o relógio

Um equipamento que passou meses desligado pode não saber a data necessária para validar um certificado. Ao mesmo tempo, obter o horário por um serviço protegido talvez dependa da validação prévia desse certificado. O Roughtime procura romper esse círculo: oferece um intervalo aproximado autenticado e deixa evidência externa quando as fontes escolhidas se contradizem.

O documento atual é draft-ietf-ntp-roughtime-19, publicado em 17 de março de 2026, com status Experimental pretendido. A IESG o aprovou no mesmo dia. O Datatracker o coloca agora na fila do RFC Editor; em 4 de setembro, o estado de produção passou a In Progress (Second Edit). Isso não o transforma em RFC publicado. Nesta apuração, ele continua sendo um Internet-Draft sem número final.

O cliente começa com um nonce novo. A resposta traz um ponto médio e um raio, formando o intervalo em que o servidor situa a hora real. A assinatura cobre um compromisso em árvore de Merkle associado ao nonce. Assim, é possível verificar que o detentor daquela chave de longa duração produziu a resposta depois de receber a consulta.

Uma assinatura válida pode cobrir um intervalo errado. Configuração defeituosa, referência externa corrompida, comprometimento do servidor ou mentira deliberada produzem a mesma autenticidade criptográfica. Por isso, no modo com múltiplos servidores, parte de uma resposta alimenta a consulta seguinte. A sequência limita as combinações de intervalos que poderiam ter ocorrido.

Se os tempos assinados não couberem nessa ordem, solicitações, respostas, chaves e material aleatório podem ser enviados a outro verificador. A conclusão é resistente, mas estreita: pelo menos uma fonte forneceu horário errado. Dependendo da cadeia, não há base para escolher uma única chave como culpada.

“Esta chave assinou”, “estas respostas se contradizem” e “esta chave deve sair da lista” são afirmações diferentes. O protocolo sustenta as duas primeiras; a terceira pertence a outro plano de decisão.

O rascunho declara onde sua autoridade acaba

A revisão 19 afirma que ainda é preciso experiência operacional com serviços que mantêm e distribuem listas confiáveis e processam relatórios. Ela limita a especificação ao protocolo no fio e aos formatos. Não define como manter a lista nem qual política aplicar.

O texto também diz que um mecanismo adicional de revisão e exclusão é necessário para um relatório levar à retirada de confiança. As regras operacionais de aceitação ou rejeição ficam fora do escopo. Nas considerações de segurança, a infraestrutura para manter listas e adjudicar violações é chamada de essencial.

Esse limite não desaparece com mais criptografia. Assinaturas e vínculos entre nonces admitem verificação determinística. Atribuir causa exige examinar dependências comuns, custódia de chaves, raio declarado, segundos intercalares, software e telemetria. Aplicar uma sanção exige definir proporcionalidade, duração, independência e continuidade.

O termo malfeasance pode sugerir intenção ilícita. A prova mostra inconsistência; a causa pode ser erro, invasão ou fraude. A primeira classificação pública deve ser contradição verificada, atribuição pendente. Preservar a incerteza não enfraquece a evidência: impede que o nome do formato funcione como veredicto.

Falhas de assinatura e outros erros de protocolo, por sua vez, não devem gerar esse relatório. Essa separação mantém um significado específico e impede que o canal de atribuição vire uma caixa geral de alertas.

A lista executa uma política de confiança

As chaves públicas duradouras são as raízes de confiança do Roughtime. O cliente precisa de pelo menos três servidores operacionais administrados por partes distintas e deve atualizar sua visão de quais continuam confiáveis.

O formato JSON comum comporta nome, endereço, versões e chave, além de fontes para outras listas e URL HTTPS para relatórios. O suporte é opcional; clientes podem configurar suas fontes por outros meios.

Isso separa interoperabilidade de monopólio. Um sistema operacional pode publicar uma lista, uma empresa pode manter outra e uma comunidade de pesquisa pode sustentar uma terceira. Adotar, atrasar, recusar ou bifurcar uma atualização é decisão local, não infração ao protocolo.

Mesmo assim, editar a lista tem consequência. Incluir uma chave admite suas respostas no futuro. Removê-la diminui o conjunto dos clientes que adotarem a revisão. Atrasar prolonga a exposição; agir cedo demais pode eliminar diversidade e deixar menos de três operadores independentes. Restaurar sem histórico apaga a memória do incidente.

O mantenedor exerce a seleção que usuários lhe delegaram. Ele não possui jurisdição universal sobre o servidor. Uma remoção só se torna estado operacional onde a lista nova é recebida, autenticada e aceita.

O recuo exponencial não pode virar perda de prova

Ao detectar a contradição, o cliente deveria produzir um relatório quando possível, avisar o usuário e medir novamente. Se a lista fornecer destino, envia por HTTPS.

Uma falha popular pode gerar milhares de envios simultâneos. O rascunho exige recuo exponencial. A regra protege o receptor, mas o cliente precisa manter o relatório intacto enquanto espera.

O receptor deveria identificar o conteúdo por hash, confirmar custódia durável e separar cópias idênticas de cadeias realmente diferentes. Reenvios não são votos adicionais. Agrupar tudo que menciona a mesma chave também pode ocultar regiões, versões ou dependências distintas. Um recibo de entrada confirma “armazenado”, nunca “revogado”.

Os dados pessoais devem ser minimizados. A verificação demanda mensagens e chaves, não necessariamente identidade persistente do equipamento. Uma infraestrutura de prestação de contas não precisa catalogar seus observadores.

Atribuição precisa de um estado, não de aparência binária

Às vezes duas respostas coerentes isolam uma terceira impossível. Em outros casos há apenas duas versões incompatíveis. Servidores diferentes podem compartilhar operador, fonte superior ou falha de software. Uma chave pode ter sido furtada. Uma minoria pode estar correta diante de fontes correlacionadas.

A revisão deve repetir assinaturas, vínculos, intervalos, radius e tratamento de segundos intercalares, além de conferir se a captura está completa. O resultado deve escolher uma descrição honesta: chave identificada, conjunto candidato ou contradição sem atribuição.

Registros do operador e referências independentes podem fortalecer o caso, mas entram com outra proveniência. Colocá-los ao lado do relatório não os converte em prova do protocolo.

Remoção permanente automática no primeiro relatório válido troca precisão por velocidade. Esperar certeza absoluta inutiliza a capacidade de alerta. Entre os extremos cabem quarentena ou redução de peso temporária, investigação, justificativa publicada e decisão com validade definida.

NTS protege o canal; Khronos protege a seleção

A RFC 8915 define o NTS com TLS e criptografia autenticada para os intercâmbios NTP. O cliente verifica origem, integridade e proteção contra repetição dentro do modelo. O NTS não torna correto o relógio autenticado.

O Roughtime pode fornecer o intervalo inicial necessário para validar o certificado de estabelecimento NTS e acrescenta evidência externa de contradições entre fontes assinadas. São funções complementares.

O Khronos, na RFC 9523, reforça seleção e filtragem contra adversários que desviam a hora. Ele protege a decisão do cliente. O Roughtime produz material que um terceiro também pode conferir. Uma boa seleção não escreve um processo de responsabilização; uma boa prova não seleciona a próxima lista.

As RFCs 8633 e 7384 reforçam diversidade, monitoramento e modelos de ameaça para fontes de tempo. Nenhuma delas cria, a partir de um algoritmo, uma autoridade global de exclusão.

O recibo portátil de exclusão de confiança

Daniel Kade propõe um recibo portátil de exclusão de confiança para documentar a passagem do fato técnico à mudança local. Não é nova mensagem do Roughtime nem tribunal central.

Primeiro, o recibo fixa hash do relatório, cadeia completa, versão do verificador, resultado de assinaturas e nonces, e hash exato da lista usada pelo cliente. O contexto de coleta fica restrito ao necessário.

Depois, registra se há chave identificada, conjunto candidato ou contradição não resolvida. Nomeia revisor autorizado, conflitos de interesse, evidências externas, motivo, confiança e prazo.

A ação vem em campo próprio: quarentena, reponderação, remoção ou restauração. Hashes anterior e posterior da lista, sequência, assinante e vigência formam uma transição verificável. Medida temporária expira se não for renovada com base explícita.

A distribuição também ganha prova própria. Endpoints e arquivo de transparência mostram o que foi oferecido, enquanto métricas agregadas indicam quais hashes os clientes instalaram, com que atraso e quais políticas recusaram. Publicação não é adoção.

Por fim, há correção. O operador pode demonstrar comprometimento de chave, reparar a referência, rotacionar identidade ou contestar a inferência. A restauração acrescenta uma transição assinada sem apagar o relatório original.

A confiança muda na ponta. Um anúncio não altera cache nem configuração fixada. Depois de aplicar a remoção, ainda é preciso conferir se restam três fontes independentes. Caso contrário, a defesa contra uma possível fonte ruim pode destruir a capacidade de inicialização segura.

O Roughtime torna uma contradição específica difícil de negar. A governança deve tornar julgamento, publicação, adoção e correção igualmente visíveis, sem transformar evidência portátil em licença para comandar todos os clientes.

Fontes