Roughtime z RFC 10049 dá klientovi důkaz, že některý časový server poslal špatný čas

Pracovní skupina IETF pro NTP uzavřela práci na protokolu Roughtime. Dokument vyšel 5. října 2026 jako RFC 10049 a je vedený jako experimentální: čeká se od něj hlavně provozní zkušenost, ne okamžité nasazení. Podepsaní jsou pod ním Watson Ladd z Akamai Technologies a Marcus Dansarie z Netnodu.

Důvod, proč protokol vznikl, shrnuje jeho vlastní úvod. NTP postrádá základní bezpečnostní prvky a ani novější Network Time Security (RFC 8915) nedává klientovi možnost poznat, jestli se server chová správně. K tomu je tu potíž se startem: ověření certifikátu X.509 potřebuje znát čas, a zařízení, které právě naběhlo, ho znát nemusí.

Nonce v dotazu, podpis v odpovědi

Klient pošle v dotazu 32bajtový nonce, tedy náhodné číslo na jedno použití. Server zahašuje celý dotaz, vloží výsledek jako list do Merkleho stromu a podepíše kořen toho stromu spolu s časem. Podpis tím dokládá, že odpověď vznikla až po dotazu, a strom dovolí serveru rozložit jednu poměrně drahou podpisovou operaci mezi víc klientů najednou. Roughtime jede po UDP i po TCP a server má podporovat obojí.

Klíče jsou dva. Dlouhodobý klíč Ed25519 je kořen důvěry a klient podle něj server pozná. Tím se podepisuje dočasný klíč s uvedeným oknem platnosti a teprve ten podepisuje jednotlivé odpovědi. Smysl je prostý: stroj vystavený do internetu tak dlouhodobý klíč mít nemusí.

Proč „hrubá“ synchronizace

Odpověď nese časové razítko a k němu tag RADI, tedy odhad přesnosti v sekundách. Server ručí za to, že skutečný čas leží uvnitř intervalu daného razítkem a touto hodnotou. Nula se do RADI dát nesmí a server, který nemá informace o přestupných sekundách, má nastavit aspoň tři sekundy. Roughtime tedy NTP nenahrazuje. Dokument naopak popisuje opačné použití: tím intervalem se dá omezit chyba, kterou do měření NTP nebo PTP vnese útočník.

Důkaz se skládá z řetězce odpovědí

Jedna odpověď doloží jen to, že ji server podepsal až po dotazu, ne že je čas v ní správný. Důkaz vzniká až ze série. Klient si ze seznamu vybere aspoň tři servery, které neprovozují titíž lidé, a obejde je po jednom; celé kolo pak ve stejném pořadí zopakuje. První nonce je náhodný, každý další vznikne hašováním celé předchozí odpovědi i s hlavičkou, ke které se připojí dalších 32 náhodných bajtů. Odpovědi se tím zřetězí do pořadí, které jde doložit.

Pak už je to jedna nerovnost. U každé dvojice odpovědí musí platit, že dolní mez času z té dřívější nepřesáhne horní mez času z té pozdější. Když podpisy sedí a tahle podmínka ne, aspoň jeden ze serverů poslal špatný čas. Klient z toho složí hlášení v JSONu s vlastním typem obsahu application/roughtime-malfeasance+json a pošle ho na adresu, kterou uvádí seznam serverů.

Co se s hlášením stane dál, RFC neřeší. Kdo seznamy serverů udržuje, kdo hlášení posuzuje a kdo serveru odebere důvěru, zůstává mimo rozsah dokumentu. Text k tomu jen nadhazuje, že jednou možností je online fórum, kde případy po přečtení posoudí sbor lidských pozorovatelů.

Server schválně odpovídá špatně

V protokolu je zabudovaný grease. Server má část odpovědí posílat vadných: bez povinných tagů, s číslem verze, které klient nenabídl, s nedefinovanými tagy nebo rovnou s neplatným podpisem a špatným časem. Klient takovou odpověď musí odmítnout. Jde o dvě věci naráz. Jednak aby protokol nezkostnatěl a dala se do něj časem přidat rozšíření, jednak aby se poznalo, že klient podpisy opravdu kontroluje. Jedna kombinace je přitom zakázaná: platný podpis pod špatným časem server poslat nesmí.

Odpověď nesmí být větší než dotaz

NTP posloužilo k zesilovacím útokům právě proto, že odpovídá víc, než dostane. Roughtime na to má dvě pravidla. Dotaz přes UDP má mít aspoň 1024 bajtů a dorovnává se výplňovým tagem ZZZZ; server nesmí poslat odpověď delší, než byl dotaz. Na kratší dotazy odpovídat nemusí vůbec.

Ed25519 je jediná podpisová sada

Dokument sám píše, že verze popsaná v RFC 10049 nepřežije nástup kvantových počítačů, protože Ed25519 proti nim odolný není, a že bude muset vzniknout verze další. Jinde se postkvantové algoritmy do protokolů IETF už dostaly: RFC 10042 popsalo tři hybridní výměny klíčů pro SSH. Jediný vyjednávací bod v podobě čísla verze zvolili autoři schválně: sada povolených algoritmů by se podle nich roztříštila do nastavení, které si každý provozovatel udělá po svém.

V praxi se jede na starých portech

IANA přidělila službě roughtime port 5319 pro TCP i UDP. V rejstříku služeb a portů je zapsaný 27. března 2026 a jako odkaz u něj pořád stojí koncept draft-ietf-ntp-roughtime-19, ne číslo RFC. Téhož dne vznikla skupina rejstříků Roughtime s osmnácti tagy a se seznamem verzí; i tam odkazy míří na koncept.

Veřejných serverů je zatím málo a port 5319 u žádného z nich nestojí. Seznam udržovaný v repozitáři cloudflare/roughtime vede čtyři: vlastní server Cloudflare na adrese roughtime.cloudflare.com:2003 a tři další, roughtime.int08h.com, roughtime.se a time.txryan.com, shodně na portu 2002. Cloudflare svou službu označuje za beta a upozorňuje, že se kořenový klíč může změnit; u staršího serveru na portu 2002 uvádí jako datum vyřazení 30. června 2024. Server roughtime.se o sobě píše, že implementuje draft-19, tedy devatenáctou a poslední revizi návrhu, ze které RFC vzniklo; běží na programu roughtimed, hostuje ho STUPI AB ve Stockholmu a je přímo připojený k atomovým hodinám.

Čtyři servery jsou přitom těsně nad minimem, které RFC po klientovi chce. Aspoň tři, a od různých provozovatelů.

Šest let a osm měsíců

První verzi návrhu poslali do pracovní skupiny 30. ledna 2020 Aanchal Malhotra z Bostonské univerzity, Adam Langley z Googlu a Watson Ladd, tehdy z Cloudflare. Tehdy měl dokument mířit mezi informační RFC. O devatenáct revizí později je z něj experimentální RFC, Ladd je podepsaný za Akamai a druhým autorem je Marcus Dansarie z Netnodu. Malhotra a Langley zůstali v poděkování jako autoři raných verzí.

Zdroje: RFC 10049; historie konceptu draft-ietf-ntp-roughtime v datatrackeru IETF; draft-ietf-ntp-roughtime-00; rejstříky Roughtime u IANA; dokumentace Cloudflare Time Services; roughtime.se.