Minulý týden vyšel na serveru Root.cz pěkný článek DNSSEC jako bezpečné úložiště SSH klíčů, který byste si měli přečíst, pokud chcete, aby vám tento blogpost dával aspoň nějaký smysl. Ve zmíněném článku zaznělo jedno takové povzdechnutí „Bohužel, specifikace záznamu SSHFP dosud nebyla rozšířena o podporu pro ECDSA klíče, jejich otisky tedy prozatím není možné do DNS uložit.“, které spustilo řetěz událostí, které (snad) vyústí v aktualizaci RFC.

Po chvilce pátrání v RFC lze zjistit, že autoři RFC 5656, které do Secure Shell protokolu přidává ECDSA algoritmus, opravdu zapomněli zaktualizovat i RFC 4255 definující SSHFP záznam. Seznam algoritmů pro klíče a jejich otisky jsou udržovány v registru IANA v seznamu DNS SSHFP Resource Record Parameters a je možné je zaktualizovat pomocí mechanismu „IETF Consensus“, který je definovaný v BCP 26:

IETF Consensus – New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).

Ve zkratce řečeno, pro aktualizaci seznamu algoritmů je zapotřebí samostatné RFC. Jelikož pracovní skupina secsh je již uzavřena, tak zbývaly dvě možnosti – najít jinou pracovní skupinu, která by byla blízko, nebo nový draft publikovat jako individuální.

Tak či onak nový Internetový Draft (I-D) se nenapíše sám… a jelikož byl DNSSEC nedávno obohacen o rodinu algoritmů SHA-2, tak nebylo potřeba začínat na zelené louce, ale bylo možné se inspirovat již schváleným RFC. Také proto, ale nejen z tohoto důvodu, nový návrh rozšiřuje záznam SSHFP i o otisky pomocí SHA-256. Původně draft obsahoval i SHA-385 a SHA-512, ale nakonec na základě komentáře Ólafura Guðmundssona (předsedajícího pracovní skupině DNSEXT) byl výčet algoritmů zredukován jen na SHA-256 (aneb pokud to stačí pro otisk v DS záznamu, tak to musí stačit i pro SSHFP záznam). Další komentáře, které jsme dostali a následně začlenili do návrhu, byly od Stephena Kenta (ředitel oblasti Security).

Jedna z připomínek byla, zda-li by draft nemohl také obsahovat příklady nových záznamů. Což bylo již kousek od toho napsat funkční implementaci nových algoritmů do OpenSSH, což, jak se nakonec ukázalo, nebyl nijak heroický výkon a výsledek (používejte pouze na vlastní riziko) naleznete v patchi ssh-sshfp-ecdsa.patch.

Výsledný návrh nového I-D byl publikován pod názvem draft-os-ietf-sshfp-ecdsa-sha2 (zdrojové xml). Stephen Kent také navrhl, že bude nejlepší poslat nové I-D do obecné skupiny SAAG, což proběhlo hned po nahrání I-D do nástrojů IETF. Zatím se k novému návrhu nikdo nevyjádřil, takže doufejme, že je to kvůli tomu, že je to vcelku dost nudný návrh RFC :). Těsně před psaním tohoto příspěvku jsem ředitele oblasti Security požádal, zda-li by náš návrh nesponzoroval. Takže držme palce, aby tento jednoduchý návrh (ECDSA bude mít číslo 3, SHA-256 bude mít číslo 2), který ovšem v jazyce RFC znamená 9 stran textu :), hladce projde schvalovacími procesy IETF.

Na závěr bych chtěl poznamenat, že z hlediska procesů IETF je jedno, jestli je autor Internetového Draftu dlouhodobě zapojen do práce IETF nebo jen přijde, napíše návrh a zase odejde. Za CZ.NIC můžu říci, že bychom byli velice rádi, kdybychom mohli k práci pro IETF přitáhnout více lidí z ČR. K sérii popularizačních článků, které vyšly na Lupě (Cesta do hlubin IETF, Odkud pochází Internetové standardy (aneb bylo jednou jedno RFC) a Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF), tak přidáváme tuto veřejnou nabídku.

Pokud máte nápad na nový protokol, standard nebo jen menší či větší vylepšení stávajícího (viz toho rozšíření SSHFP o nové algoritmy), tak se na nás můžete kdykoliv obrátit. Velice rádi vám s psaním návrhu nového RFC pomůžeme.

Ondřej Surý