Podpora eliptických křivek v DNSSECu
Algoritmy založené na eliptických křivkách jsou aktuálním módním trendem v kryptografii, a tak není divu, že ani DNSSEC se jim nevyhýbá. Mezi hlavní výhody eliptických křivek patří rychlejší generování podpisů a především pak podstatně kratší délka klíče při stejné síle. Jak je možné ověřit například na serveru Keylength.com, ECDSA klíč délky 256 bitů poskytuje bezpečnost odpovídající RSA klíči délky kolem 3072 bitů. Takový klíč je tedy pravděpodobně bezpečnější i než 2048bitový RSA klíč samotné kořenové zóny. Malá velikost klíče i podpisů je obecně pro DNS výhodná, neboť s narůstáním objemu DNS zpráv dochází k jistým provozním problémům, jako je fragmentace, přechod na transportní protokol TCP nebo nárůst zesilovacího faktoru při kybernetických útocích.
Podporu pro eliptické křivky v DNSSECu zavádí RFC 6605, které vyšlo již v roce 2012. Konkrétně jsou definovány dva algoritmy a sice ECDSAP256SHA256 s číslem 13 a ECDSAP384SHA384 s čílem 14. Jak názvy napovídají, jedná se o použití eliptických křivek P-256, resp. P-384 podle specifikace FIPS 186–3 a hashovací funkce SHA256, resp. SHA384.
Jedinou, zato ale zásadní, nevýhodou použití ECDSA algoritmu v DNSSECu je jeho nepodpora staršími validátory. Ta vychází zejména z nejistoty ohledně existence patentů, kvůli které některé distribuce podporu eliptických křivek v OpenSSL záměrně vypínaly. Ještě v roce 2014 George Michaelson z laboratoří APNIC před jejich použitím varoval. Od té doby však nastal velký pokrok, validaci ECDSA podpisů zvládne ve výchozím nastavení většina aktuálních linuxových distribucí. Důležité také je, že i při nepodpoře ECDSA algoritmu validátorem nedojde k žádnému fatálnímu selhání, validátor zónu propustí bez validace stejně, jako by nebyla podepsána vůbec.
O tom, jak je na tom váš DNS resolver s podporou různých DNSSEC algoritmů se můžete snadno přesvědčit pomocí utilitky alg_rep. Ta provede úplný test všech definovaných DNSSEC algoritmů proti všem typům DS záznamů a oběma typům NSEC záznamů. Výsledek je zobrazen v přehledné tabulce:
Zone dnssec-test.org. Qtype DNSKEY Resolver [2001:4860:4860::8888]
DS : 1 2 3 4 | 1 2 3 4
ALGS : NSEC | NSEC3
alg-1 : S S S S | x x x x => RSA-MD5 OBSOLETE
alg-3 : - - - - | x x x x => DSA/SHA1
alg-5 : V V - V | x x x x => RSA/SHA1
alg-6 : x x x x | - - - - => DSA-NSEC3-SHA1
alg-7 : x x x x | V V - V => RSA-NSEC3-SHA1
alg-8 : V V - V | V V - V => RSA-SHA256
alg-10 : V V - V | V V - V => RSA-SHA512
alg-12 : - - - - | - - - - => GOST-ECC
alg-13 : V V - V | V V - V => ECDSAP256SHA256
alg-14 : V V - V | V V - V => ECDSAP384SHA384
V == Validates - == Answer x == Alg Not specified
T == Timeout S == ServFail O == Other Error
DS algs 1=SHA1 2=SHA2-256 3=GOST 4=SHA2-384 V ideálním případě budou ve všech polích tabulky znaky V, značící úspěšnou validaci, případně x pro neexistující kombinace algoritmu a NSEC záznamu. Pokud je v poli znak -, znamená to, že validátor daný podpis nepodporuje a data propustil bez ověření. Znak S pak značí návratový kód selhání serveru. Ve výše uvedeném příkladu takovou odpověď vrací zóny podepsané zastaralým protokolem RSA-MD5.
Nevinné lži při online podepisování
Zásadním návrhovým požadavkem, který do velké míry ovlivnil výsledný návrh protokolu DNSSEC, byla podpora offline podepisování, tedy to, aby autoritativní DNS server mohl pracovat zcela bez přístupu k privátnímu klíči, pomocí kterého jsou podpisy vytvářeny. Splnění tohoto požadavku spolu s podporou pro tzv. žolíkové DNS záznamy a odolností proti útokům přehráním zaznamenané komunikace si vyžádalo poměrně komplexní systém NSEC záznamů, který byl ještě dále zkomplikován přechodem na NSEC3 záznamy za účelem znesnadnění procházení zónového souboru postupnými dotazy.
Důsledkem je, že zatímco pozitivní odpověď na DNS dotaz je přímočará – k dotazovaným záznamům se jednoduše připojí podpis – negativní odpověď musí obsahovat mnohem víc dat: kromě tradičního SOA záznamu a jeho podpisu ještě NSEC záznam prokazující, že dotazované jméno neexistuje a NSEC záznam prokazující, že neexistuje ani žolíkový záznam, který by pokrýval dotazované jméno, oba záznamy ještě doprovázené podpisy. Při použití NSEC3 jsou takové záznamy dokonce tři. Stejně tak jsou komplikované i pozitivní odpovědi vzniklé z žolíkových záznamů, kde je třeba kromě podepsané odpovědi doručit i podepsaný NSEC důkaz, že opravdu neexistuje lepší záznam a bylo nutné použít žolík. Celou problematiku hezky shrnuje informativní RFC 7129. Důsledkem takto složitého systému je kromě nárůstu délky zpráv také spousta implementačních chyb, způsobujících například problémy při řetězení resolverů a validaci žolíkových záznamů.
Offline podepisování však není jediný možný způsob nasazení DNSSEC. Online podepisování může být výhodné jak pro menší instalace, tak i pro velké sítě CDN, které obsah DNS odpovědi mění v reálném čase na základě nejrůznějších faktorů. Zde je třeba zdůraznit, že přítomnost privátního klíče na DNS serveru není nic strašidelného; úplně stejně fungují snad všechny kryptografické protokoly, které znáte, namátkou třeba HTTPS nebo SSH. Přítomnost privátního klíče pak umožní zásadním způsobem zjednodušit obsah negativních odpovědí, protože odpověď obsahuje přímo podepsaný dotaz.
Tento postup se obecně nazývá NSEC/NSEC3 white lies, česky tedy nevinné lži. Zatímco v při tradičním podepisování by dotaz na neexistující jméno jablko vrátil NSEC záznam s nejbližšími existujícími záznamy, třeba banán NSEC
pomeranč, v režimu nevinných lží server vygeneruje minimální NSEC záznam, pokrývající pouze dotazované jméno, například tedy jablkn NSEC jablkp. Takový postup implementoval samotný Dan Kaminsky ve svém DNSSEC proxy serveru Phreebird a dočkal se i standardizace v RFC 4470.
S ještě zajímavější variantou nevinných lží přišla společnost CloudFlare. Jejich implementace online podepisování je zvláštní tím, že na jakýkoli dotaz odpoví pozitivně, tedy s návratovým kódem NOERROR. Pokud dotazovaná data neexistují, raději předstírají, že dané jméno sice existuje, ale nemá žádný záznam dotazovaného typu. Tímto způsobem, obsahuje negativní odpověď pouze jeden SOA a jeden NSEC záznam. Spolu s použitím ECDSA algoritmu je tak možné i negativní odpovědi stlačit pod délku zprávy 512 bajtů a ušetřit tak případné problémy s velkými DNS zprávami.
Podepisování jedním klíčem
Od počátku DNSSECu bylo doporučováno používání dvojice klíčů pro podepisování zónového souboru. Slabší klíč ZSK podepisuje všechny záznamy v zóně, silnější klíč KSK podepisuje pouze záznam DNSKEY s veřejnou částí klíče ZSK. Otisk klíče KSK je publikován v DS záznamu nadřazené zóny, čímž je sestaven řetěz důvěry.
Vizualizace hierarchie KSK a ZSK klíčů nástrojem DNSViz.net
Tímto způsobem se řeší požadavek na dostatečně krátké podpisy, aby objem DNS dat příliš nenarostl, zároveň s protichůdným požadavkem na dostatečně bezpečné klíče, aby je nebylo nutné měnit příliš často, neboť každá výměna vyžaduje (typicky manuální) komunikaci s operátorem nadřazené zóny. Obvyklá současná praxe je použití 1024bitového RSA klíče jako ZSK a 2048bitového RSA klíče jako KSK, přičemž ZSK je obvykle měněn automaticky každý měsíc, KSK manuálně po roce, dvou, nebo vůbec. Zajímavé je to zejména v kontrastu s TLS certifikáty, kde ještě nedávno existovaly kořenové certifikáty používající 1024bitové RSA klíče, vydané s platností 10 let.
Příchod eliptických křivek umožňuje i správu klíčů výrazným způsobem zjednodušit. 256bitový ECDSA klíč je silnější než běžné současné KSK klíče a zároveň generuje podpisy kratší než současné ZSK klíče. Odpadá zde tedy požadavek na častou výměnu ZSK klíče a nic nebrání podepisování celé zóny jedním klíčem, který stačí manuálně jednou za čas vyměnit.
Používání původní dvojce samostatných KSK a ZSK klíčů samozřejmě není zakázáno. Třeba dříve zmíněná společnost CloudFlare používá dvojici klíčů z důvodu bezpečnosti – ZSK klíče jsou přítomny přímo na DNS serverech ve všech uzlech, zatímco KSK klíče jsou v bezpečném kontrolovaném prostředí. V případě kompromitace ZSK klíče je možné tento vyměnit a revokovat, aniž by to vyžadovalo komunikaci s nadřazenou zónou.
Další křivky na obzoru
Standardizované křivky P.256 a P.384, které jsou v současné době jediné dvě podporované v DNSSECu, byly kryptology Danielem J. Bernsteinem a Tanjou Lange v nedávném výzkumu označeny jako nebezpečné. Zřejmě se nejedná se o nějaké bezprostřední riziko, rozhodně však není od věci podporovat i jiné křivky, takové, které zmiňovaná zpráva označuje jako bezpečné.
Jednou z nich je i Bernsteinova křivka Curve25519. Podporu pro její použití v DNSSECu v tuto chvíli navrhuje v IETF Ondřej Surý, stejně jako další křivku Ed448. Není však možné očekávat reálnou nasaditelnost těchto nových křivek dříve než za několik let.
