Technologie DNSSEC je aktuálně nasazována po celém světě. K většímu úspěchu jí ovšem chybí tzv. killer-app. Tj. takové použití DNSSECu, kvůli kterému si jej budou chtít pořídit všichni. Takovou killer-app by se mohly stát standardy ukládání kryptografických dat do DNS, na kterých se pracuje na půdě organizace IETF.

Nejprve bych ovšem krátce zabrousil do historie. Nápad ukládat veřejné části klíčů (nebo jejich otisky) do DNS není nikterak nový. První standard popisující záznam CERT, umožňující ukládat certifikáty do DNS, vytvořili v roce 1999 Olafur Gudmundsson a Donald Eastlake (RFC2538). Tento internetový standard byl v roce 2006 aktualizován Simonem Josefssonem a jeho aktuální podobu naleznete v RFC4398.

Pro SSH vznikl v roce 2006 podobný standard (RFC4255), který je podporován v OpenSSH, ale bohužel je nutné jeho podporu implicitně zapnout. Vytváření šifrovaných tunelů pomocí IPsecu můžete taktéž podpořit informací uloženou v záznamu IPSECKEY (RFC4025) z roku 2005.

Proč tedy zatím nedošlo k masivnějšímu rozšíření používání těchto šikovných pomůcek, jak publikovat veřejné klíče pomocí DNS? Jeden z velkých problémů spočíval v tom, že data, která jste dostali pomocí DNS, nebyla nijak zabezpečena. Tudíž útočník mohl libovolně podvrhnout kryptografický obsah v těchto záznamech.

Naštěstí jsme od té doby ušli dlouhou cestu zakončenou podepsáním kořenové zóny a nyní máme kryptograficky zabezpečený DNS strom, ve kterém můžeme publikovat zabezpečená data. Po počátečním šumu, který vznikl z nadšení z podpisu kořenové zóny, se většina práce naštěstí soustředila okolo IETF. Na posledním setkání IETF 78 v Maastrichtu se na neformálním meetingu (tzv. Bar BoF) potkalo asi 50 zástupců internetové komunity i komerčních firem, které tato problematika zajímá, a dohodli jsme se na postupu směřujícímu k vytvoření regulérní pracovní skupiny (WG) v rámci IETF. Po počátečních průtazích s vytvořením poštovní konference vznikl mailing list keyassure (archiv konference), ve kterém probíhá živá debata nad několika I-D, které vznikly na základě počátečního impulsu.

Aktuálně jsme společně s Warrenem Kumarim z Google vytvořili návrh zakládací listiny pracovní skupiny (za přispění diskutérů v poštovní konferenci) a poslali jsme žádost na vytvoření pracovní skupiny KIDNS (Keys In DNS). Původní záměr byl uspořádat formální BoF setkání na IETF 79 v Pekingu, viz seznam BoF, ale na základě diskuze v konferenci vyplynulo, že BoF již pro vytvoření pracovní skupiny není zapotřebí.

A co se tedy jedná? Pokud chcete provozovat web přes HTTPS (případně mít zabezpečený poštovní protokol – SMTP, IMAP, POP3), tak máte v zásadě jen jednu možnost, jak toto provést tak, aby se certifikát jevil jako důvěryhodný – a to pořídit jej u některé z certifikačních autorit, které jsou považovány za natolik bezpečné, že byli výrobci prohlížečů zařazeny do implicitního seznamu certifikačních autorit. Jak už to ovšem bývá, tak ne všechny certifikační autority jsou stejně bezpečné a bezpečnost je vždy tak silná, jako její nejslabší článek. Běžná praxe u DV (Domain Validated) certifikátů je dnes taková, že ověření validity žádosti je provedeno na základě toho, že jste schopni přijímat e-maily na doméně, pro kterou žádáte certifikát. Jinými slovy vám stačí ovládnout MX záznamy pro směřování pošty a odchytit ty správné e-maily, abyste byli schopni vytvořit certifikát pro konkrétní doménové jméno. Certifikační autority sice poskytují i certifikáty s vyšší úrovní zabezpečení tzv. EV (Extended Validation), ale ruku na srdce, kolik z vás by si všimlo, že se zabezpečení změnilo z EV na DV certifikát. A jak velké by to bylo procento z vašich přátel, rodičů, atp., kteří nejsou obdařeni bezpečnostní paranoiou jako vy.

Úkoly jsou před námi dva:

1. Umožnit validaci libovolných certifikátů, tedy i self-signed, pomocí záznamu v DNS
2. Umožnit ověření, že použitý certifikát je pravý a vlastník doménového jména jej zamýšlel použít. To je výrazné vylepšení i pro EV certifikáty.

V obou dvou případech bude nutné záznamy zabezpečit pomocí DNSSECu, aby bylo možné ověřit validitu dat, která klient dostane z DNS.

Na závěr bych uvedl seznam čtení na dlouhé noci, tedy I-D, které zatím v pracovní skupině vznikly:

• Using Secure DNS to Associate Certificates with Domain Names For TLS
• Confirming the Certificate structure in TLS with Secure DNS
• DNS Extended Service Parameters (ESRV) Record

A na úplný závěr bych vás, pokud vás tato problematika oslovuje, rád pozval do poštovní konference a snad již brzy vzniklé pracovní skupiny KIDNS.

Ondřej Surý