Кратко

  • Редакция 19 Roughtime описывает протокол с предполагаемым статусом Experimental. Цепочка подписанных обменов способна доказать, что как минимум один сервер сообщил время, несовместимое с причинным порядком, но не всякая цепочка однозначно указывает на конкретный ключ.
  • Проект задаёт форматы списка доверенных серверов и отчёта о нарушении, однако оставляет вне рамок приём доказательств, разбирательство, исключение и сопровождение списков. При этом сами эти процедуры названы необходимыми для безопасности.
  • Переносимая квитанция об отзыве доверия должна связать хеш отчёта, пределы атрибуции, уполномоченную проверку, решение, подписанный переход списков, распространение, принятие клиентом и исправление. Это предложение Daniel Kade, а не требование IETF.

Подлинный ответ может содержать неверное время

Устройство после долгого отключения может не знать дату настолько, чтобы проверить сертификат. А безопасное получение времени способно само зависеть от предварительной проверки сертификата службы времени. Roughtime разрывает эту петлю: даёт аутентифицированный приблизительный интервал и сохраняет внешнее доказательство, когда выбранные источники расходятся.

Текущий документ — draft-ietf-ntp-roughtime-19, опубликованный 17 марта 2026 года с целевым статусом Experimental. В тот же день IESG одобрила его. Сейчас Datatracker показывает очередь RFC Editor, а 4 сентября производственный статус перешёл в In Progress (Second Edit). До завершения публикации редакция 19 остаётся Internet-Draft; в этом пакете нет основания называть её опубликованным RFC или присваивать номер.

Клиент создаёт новый nonce. Сервер возвращает середину и радиус интервала, где, по его утверждению, находится истинное время. Подпись охватывает обязательство дерева Меркла, связанное с запросом. Проверяющий видит, что владелец долговременного ключа сформировал ответ после получения nonce.

Так устанавливается подлинность высказывания, а не точность часов. Исправный ключ может подписать ошибочный интервал из-за настройки, неисправного верхнего источника, компрометации или умысла. В режиме нескольких серверов материал предыдущего ответа включается в следующий запрос, и интервалы связываются с реальной последовательностью обменов.

Если они не укладываются в причинный порядок, клиент сохраняет запросы, ответы, ключи и случайный материал. Третья сторона воспроизводит противоречие. Вывод силён, но ограничен: по крайней мере один сервер дал неверное время. Иногда из самой цепочки нельзя узнать, какой именно.

Нужно различать три утверждения: ключ подписал ответ; ответы несовместимы; ключ следует удалить из списка. Первые факты может подтвердить протокол, последнее решение появляется лишь в операционной системе управления.

Проект сам проводит институциональную границу

Редакция 19 прямо говорит о необходимости опыта эксплуатации экосистемы, которая сопровождает и распространяет списки доверенных серверов и обрабатывает отчёты. Спецификация ограничена протоколом на проводе и форматами. Она не устанавливает политику списка и механизм разбирательства.

Чтобы отчёт привёл к исключению, требуется дополнительный процесс review and impeachment; он находится вне рамок. Операционные правила принятия или отклонения конкретного отчёта также не определены. Раздел безопасности называет инфраструктуру и процедуры сопровождения списков и рассмотрения нарушений существенными для защиты.

Эту границу нельзя убрать ещё одним криптографическим полем. Подписи и связи nonce проверяются детерминированно. Атрибуция требует исследовать общие опорные часы, хранение ключей, radius, високосные секунды, программные сбои и телеметрию. Мера воздействия добавляет вопросы пропорциональности, срока, независимости и непрерывности.

Слово malfeasance способно заранее внушить умысел. Доказательство показывает несогласованность. Причиной может быть ошибка, взлом или обман. Первое корректное публичное состояние — противоречие проверено, атрибуция не завершена.

Проект запрещает отправлять такой отчёт лишь из-за неверной подписи или иной ошибки протокола. Канал должен сохранять узкое значение причинного противоречия, а не превращаться в общий поток аварий.

Список — исполняемая программа доверия

Долговременные открытые ключи серверов служат корнями доверия Roughtime. Клиенту нужны минимум три работающих сервера, управляемых разными сторонами, и ему следует обновлять представление об их надёжности.

Общий JSON-формат может содержать имя, адрес, версии и ключ, а также источники других списков и HTTPS-адрес для отчётов. Поддержка необязательна; клиент вправе настраивать источники иначе.

Благодаря этому общий формат не назначает мирового хранителя. Производитель ОС, предприятие и исследовательское сообщество могут вести разные наборы. Клиент может принять, задержать, отклонить обновление или создать ответвление.

Однако редактирование списка имеет последствия. Добавление ключа допускает его ответы в будущие измерения. Удаление исключает сервер у принявших версию клиентов. Медленное действие продлевает риск; поспешное сокращает разнообразие. Тихое восстановление стирает память решения.

Хранитель списка реализует ограниченное поручение пользователей, а не юрисдикцию над сервером. Решение действует только там, где новая версия подписана, доставлена, проверена и локально принята.

Защита приёмника не должна уничтожить доказательство

Обнаружив несогласованность, клиент по возможности создаёт отчёт, уведомляет пользователя и повторяет измерение. Если список задаёт адрес, отчёт отправляется по HTTPS.

Сбой популярного сервера способен вызвать одновременный поток. Поэтому проект требует экспоненциальной задержки повторов. Она защищает приёмник, но клиент обязан сохранить исходный отчёт до успешной передачи.

Приёмная сторона вычисляет хеш содержимого, подтверждает долговременное хранение и отличает точные копии от разных цепочек. Повторная доставка — не новый голос. Сведение всех наблюдений одного ключа в одну запись, наоборот, скроет масштаб. Квитанция говорит «сохранено», но не «доверие отозвано».

Необходима и минимизация личных данных. Для проверки нужны сообщения и ключи, но обычно не постоянная идентичность устройства. Подотчётность не должна создавать каталог наблюдателей.

Атрибуция должна сохранять несколько состояний

Иногда два согласованных свидетеля изолируют невозможный средний интервал. Иногда есть лишь две противоположные версии. Несколько серверов могут зависеть от одного оператора, источника времени или дефекта. Ключ мог быть похищен. Единственный выброс может оказаться правильным при коррелированной ошибке большинства.

Эксперт повторяет все подписи, связи nonce, интервалы, обработку radius и високосных секунд, проверяет полноту сбора. Затем выбирает честный результат: определённый ключ, множество кандидатов или неатрибутированное противоречие.

Журналы оператора и независимые часы могут усилить вывод, но имеют отдельное происхождение. Приложенная операционная улика не становится математической частью Roughtime.

Автоматическое постоянное удаление по первому корректному отчёту выдаёт скорость за определённость. Ожидание абсолютной уверенности делает предупреждение бесполезным. Между ними находятся временный карантин или снижение веса, расследование, публикация причины и решение с датой пересмотра.

NTS и Khronos защищают иные границы

RFC 8915 определяет NTS на основе TLS и аутентифицированного шифрования для NTP. Клиент проверяет происхождение, целостность и защиту от повтора. NTS не гарантирует правильность часов аутентифицированного сервера.

Roughtime может дать начальный интервал, достаточный для проверки сертификата NTS-KE, и предоставляет внешнее доказательство конфликта подписанных источников. Механизмы дополняют друг друга.

Khronos в RFC 9523 усиливает выбор и фильтрацию NTP против сдвига времени. Он защищает локального клиента. Roughtime создаёт противоречие, проверяемое третьей стороной. Отбор не формирует дело об ответственности, а дело не выбирает следующий набор доверия.

RFC 8633 рекомендует множество источников и наблюдение; RFC 7384 описывает угрозы времени и зависимость сертификатов. Эти документы показывают важность задачи, но не создают универсального судью из алгоритма.

Переносимая квитанция об отзыве доверия

Daniel Kade предлагает переносимую квитанцию об отзыве доверия для документирования переходов после протокольной проверки. Это не новое сообщение Roughtime и не центральный трибунал.

Сначала фиксируются хеш отчёта, полная цепочка, программа проверки и её версия, результаты подписей и связей nonce, точный хеш списка клиента. Контекст сбора ограничивается необходимым.

Затем записываются статус атрибуции, уполномоченный эксперт, конфликт интересов, внешние данные, причина, уверенность и срок. Проверка и суждение остаются различимыми.

Действие оформляется отдельно: карантин, изменение веса, удаление или восстановление. Хеши прежнего и нового списка, последовательность, подписант и время вступления создают проверяемый переход. Временная мера истекает без явного продления.

Для распространения тоже нужны доказательства. Точки публикации и прозрачный архив показывают предложенную версию, а агрегированные данные клиентов — установленные хеши, задержки и причины локального отказа. Публикация не выдаётся за принятие.

Наконец, сохраняется путь исправления. Оператор может доказать кражу ключа, исправить источник, сменить ключ или оспорить вывод. Восстановление добавляет новый подписанный переход, не удаляя исходный отчёт.

Доверие меняется внутри клиента. Объявление не обновляет кэш и не отменяет закреплённую настройку. После удаления необходимо проверить, что осталось не менее трёх независимых источников. Иначе защита разрушит безопасный запуск.

Roughtime делает конкретное противоречие трудным для отрицания. Хорошее управление делает столь же видимыми решение, публикацию, принятие и исправление, не превращая переносимое доказательство в власть над всеми.

Источники