DNSSEC a podpis kořenové zóny
Nedávno to bylo pět let, co proběhl slavnostní ceremoniál podpisu kořenové zóny DNS. Tehdy, 16. června 2010 v 18 hodin (UTC), byl zahájen proces směřující k tomu, aby šel v celosvětovém stromě DNS používat systém DNSSEC zajišťující důvěryhodnost odpovědí na dotazy do DNS.
V rámci ceremoniálu byl vygenerován počáteční klíč k podepisování klíčů (Key signing key, KSK). Ten je nyní uložen jednak ve čtyřech hardwarových bezpečnostních modulech (které nemůže opustit) a současně existuje také možnost jeho obnovy pro případ poruchy nebo zničení všech modulů.
Ondřej Surý při přednášce o výměně KSK
Aby nemohl nikdo kořenovou zónu ovládnout, byl klíč zašifrován a lze ho dešifrovat klíčem rozděleným na fragmenty, z nichž má určitou část na kartě každý ze sedmi „vyvolených“ (Recovery Key Share Holders, RKSH). Pro rekonstrukci klíče je potřeba účast nejméně pěti lidí z této skupiny. Jedním z této sedmičky je i Ondřej Surý ze sdružení CZ.NIC, jenž na konferenci Internet a Technologie 15.2 hovořil o chystané výměně KSK.
Přečtěte si rozhovor s Ondřejem Surým – například o DNSSEC a DANE, Knot DNS, Datovce nebo tvorbě balíčků pro Debian.
Proces výměny klíče
Zatímco klíče k podepisování zón (Zone signing keys, ZSK) se pravidelně obměňují, KSK se dosud neměnil. „Ten klíč už je tam pět let a po pěti letech z požadavků na rootovou zónu musí proběhnout výměna,“ zdůvodňuje Ondřej Surý chystanou výměnu klíče.
Proces je připravován tzv. design týmem. V něm jsou začleněni zástupci organizace ICANN, firmy Verisign (která spravuje ZSK), americký úřad NTIA (obdoba ČTÚ) a sedm dobrovolníků, mezi něž patří i Ondřej Surý. „Ten design team měl za úkol vytvořit plán toho, jak se rollover klíče dá udělat. Cílem je navrhnout postup – technický, provozní, kryptografický, komunikační – a dát [organizaci] ICANN doporučení, jak ten plán provést. A také udělat zhodnocení dopadů této změny.“
Dobrovolníci připravující výměnu klíčů (prezentace ICANN)
Vytvořený dokument prochází procesy, které zahrnují kromě jiného i veřejné připomínkování – to skončilo 15. října 2015. Nyní probíhá zapracovávání připomínek. „V polovině prosince jsme si dali takový deadline,“ říká Ondřej Surý, „do které bychom s tím dokumentem skončili, udělali finální verzi.“
Ohledně načasování výměny klíčů (KSK i ZSK) vznikl informativní dokument RFC 7583.
Mezi doporučení design týmu patří například maximální neměnnost procesu, aby se v něj nesnížila důvěra. Dále by například bylo dobré notifikovat tvůrce DNS serverů a operačních systémů – tedy například linuxových distribucí, ale i třeba systému Windows – a na přípravě změn v DNSSEC s nimi spolupracovat. ICANN by měl také zveřejnit oficiální návod, jak na změnu KSK správně reagovat.
Stavový diagram výměny klíčů podle RFC 5011 (prezentace ICANN)
Zásadním dokumentem pro výměnu klíčů je RFC 5011. Ten popisuje, jak lze klíče měnit za běhu. „Přidám nový klíč do zóny, podepíšu ho tím starým a teď si hraji s bity v příznacích DNSKEY, tak abych nakonec tím novým klíčem po nějakém čase podepsal ten starý klíč, který má nastavený REVOKE bit.“ Celkově je stavů víc a reflektují i některé situace, kdy je potřeba se vrátit zpět.
Rotace ZSK probíhají v desetidenních časových slotech. Doporučení design teamu říká, že by bylo dobré se tohoto časového diagramu držet i pro KSK. Na následujícím obrázku je vidět, jak probíhají výměny ZSK a jak do toho lze přidat výměnu KSK.
Časový harmonogram pro výměnu klíčů (prezentace Geoffa Hustona)
V případě KSK to tedy proběhne tak, že se nový klíč nejdřív zveřejní (a podepisuje se stále původním), pak se jím začne podepisovat, následně se starý klíč odebere, po určité době se zveřejní revokovaný a na závěr se opět odebere. Zůstane tedy zveřejněn a používán už pouze nový klíč. Dokud nedojde k revokaci starého klíče, dá se vrátit do užívání, nastanou-li potíže s novým klíčem.
S výměnou klíčů souvisí jeden problém: velikost paketu, kterou je v některých fázích potřeba navýšit. „IP fragmenty jsou identifikovány pouze 16bitovými ID. Dnes už je lze docela úspěšně hádat a dá se i zlepšit to hádání pomocí nějakých algoritmů. Integritu zajišťuje zase jen jednoduchý 16bitový checksum. DNS hlavička, dojde-li k fragmentaci, je pouze v prvním paketu. S MTU, tedy jak velké pakety to propouští, se dá bohužel manipulovat.“
Hrozí tedy útok na DNS pomocí fragmentace UDP. Pokud je útočník ve stejné síti, kterou od vnějšího světa odděluje NAT (který přiděluje identifikátory fragmentů), je takový útok relativně jednoduchý a útočník může nahradit druhý fragment nějakým svým. Problémy hrozí hlavně u IPv4, kde lze MTU zmenšit teoreticky až na 68 B; u IPv6 je minimum 1280 B. Nasazení IPv6 tedy poskytuje určitou ochranu, i když při rotaci klíčů se velikost paketu v některých fázích může přes zmíněnou hranici dostat.
Design team doporučil zachovat existující algoritmus pro podepisování. „Proč teď nepoužívat eliptické křivky? RSA se zdá, že v této velikosti – 2048 bitů –, bude dostatečně bezpečné pro následujících pět let. (…) Další důvod, proč to nefunguje, je, že minimálně Unbound vyžaduje podpis oběma algoritmy. (…) Aktuálně jsou v DNSSEC (v RFC 6605) standardizovány jen algoritmy ECDSA a NIST křivky. (…) Tyto křivky mají některé špatné vlastnosti.“
Na závěr přednášky uvedl Ondřej Surý nejdůležitější doporučení design teamu: „Kdy ten rollover by se měl stát. (…) Trochu se to posunulo. Do konce roku 2016 se to stihne nachystat, a ty změny, které byly v tom obrázku, by mohly začít v lednu 2017.“ V dubnu roku 2017 by se měl tedy už začít používat nový klíč.
Registrace a prodej knih na konferenci IT 15.2
