Liberální nebo striktní? A co na to All Blacks?

Když John Postel v roce 1980 definoval pravidlo robustnosti (známé také jako Postelův zákon), tak se zdálo být rozumné jej definovat jako: „Buď liberální v tom, co přijímáš, ale buď striktní v tom, co vysíláš.“ O pár let později bylo toto pravidlo rozšířeno v RFC 1122 o požadavek nejen přežít divoké prostředí špatně naformátovaných paketů, ale také nadále spolupracovat a komunikovat s implementacemi, které se takto neslušně chovají. Internet byl ve svých počátcích a bylo těžké odhadovat, jaká všechna zařízení budou do sítě připojena a jak dobře nebo špatně budou naprogramována.

Nicméně zpátky k návrhu internetových protokolů. Již o deset let později v roce 2001 popisuje Marshall Rose v RFC 3117 problémy, které přináší aplikace principu robustnosti do interoperability aplikací. Představte si, že máme dvě implementace:

  • implementaci Locke, kterou psal hodně šikovný programátor a docela si s ní vyhrál, takže je velmi liberální a dokáže přijmout a zpracovat libovolně naformátovaný paket a…
  • implementaci Demosthenes, kterou psal programátor hodně ve spěchu a posílá takové pakety, ze kterých se dělá trochu špatně i směrovačům po cestě.

Locke si s Démosthenem v klidu dokáží povídat. Locke se sice občas diví, co to Démosthenés říká, ale vcelku dobře si rozumějí a komunikace volně plyne. To se ovšem radikálně mění ve chvíli, kdy na scénu přichází implementace Rochester, kde byl programátor velmi striktní a naprogramoval Rochestera tak, že přesně odpovídá specifikaci protokolu a odmítá jakékoli odchylky od standardu, zatímco si Locke s Rochesterem může bez problému popovídat (ostatně jsou oba dva angličané). Dokonce pro Lockeho je komunikace s Rochesterem jednodušší, protože oba dva při komunikaci dodržují správný komunikační protokol. Naopak Démosthenés má se svou antickou řečtinou najednou problém. Démosthenés se může snažit mluvit s Rochesterem jak chce, ale ten mu prostě nemůže rozumět, protože nemluví společným jazykem.

A co by na to řekli All Blacks? Kdyby se o Postelově zákonu dozvěděli v půlce prosince minulého roku, tak by asi zareagovali takto:

Proč? Správci novozélandské domény .NZ v půlce prosince dokončili proces implementace DNSSEC, vypublikovali správný klíč a poslali jej do kořenové zóny. Následně byli upozorněni, že jejich klíč má nezvyklou sekvenci znaků v místě, kde je uveden RSA exponent. Pro srovnání si tento rozdíl pojďme ukázat konkrétně.

Klíč pro doménu .CZ vypadá takto:


cz.	     IN DNSKEY 257 3 10 (
		AwEAAaVU8EMQrZ6Tix2zBaAmizMQ7W0m94qSJUXV4eVW
		S9ZpXh9t1uj8U/B5Nnqge4G0Te0/NJIqflihZKXs8Hyh
		JqjF852RKnvNWPu2wMujYjHP0T4lIhu4rTym9+sPNsfi
		oqvMyyDeqyhVPx21nvLW5oaKjaLd3XJxijRbDTddRU97
		mJVVS50PKdDmh5n/4KdRKV7ifR2Ap8L1bvUiCOxl4GAq
		LoXft+L896bkVj6mefdCSyYaCbgsDc2+10ZBOSF1t89N
		J6O1yO+y5/7vS3dYKEqj+p4ygaCY0spvrhZxncUeASix
		g224bNYZM5TLk2/YoKgAEjaIoCwu7SAXB5iUvLU=
		) ; key id = 14568

Pokud rozkódujeme prvních pár znaků, dostaneme následující výstup:

$ dig dnskey cz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b
0000000: 00000011 00000001 00000000 00000001 10100101 01010100  .....T
0000006: 11110000 01000011 00010000 10101101 10011110 10010011  .C....

Délka exponentu je uvedena na prvním místě (00000011), tj. exponent je dlouhý tři bajty. Exponent je v tomto případě 65537 (00000001 00000000 00000001).

DNSSEC klíč pro novozélandskou doménu vypadal takto:

nz.          IN DNSKEY 257 3 8 (
                BAABAAGwfTiEoh71o6S55+Mdy1qqVRnpKY1VHznrv+wx
                rPfvRGB5VivFFPFN+33fsaTxJQTceOtOna7IKxTffj6p
                bBG4a9vtk2FqF551IwXomKWJnzRVKqYzuAx+Os/5gLIN
                BH7+qRWAkJwCdQXIaJGyGmshkO5Ci5Ex5Cm3EZCeVrie
                0fLI03Ufjuhi6IJ7gLzjEWw84faLIxWHEj8w0UVcXfaI
                2VL0oUC/R+9RaO7BJKv93ZqoZhTOSg9nH51qfubbK6FM
                svOWEyVcUNE6NESYEbuCiUByKfxanvzzYUUCzmm+JwV7
                7Ebj3XZSBnWnA2ylLXQ4+HD84rnqb1SgGXu9HZYn
                ) ; key id = 2517

Opět rozkódujeme prvních pár bajtů:

dig dnskey nz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd
-l 12 -b
0000000: 00000100 00000000 00000001 00000000 00000001 10110000  ......
0000006: 01111101 00111000 10000100 10100010 00011110 11110101  }8....

Již na první pohled je vidět, že exponent je v tomto případě delší (00000100), tj. 4 bajty. Nicméně hodnota exponentu (00000000 00000001 00000000 00000001) zůstává stejná, tedy rovna 65537.

V čem je tedy zádrhel? Dle standardu RFC 3110, který definuje kódování RSA klíčů pro použití v DNS, jsou počáteční nuly v exponentu zakázány. A nyní se dostáváme zpátky k počátečnímu sporu Postel vs Rose.

Správci novozélandské domény samozřejmě nasazení DNSSEC klíče pečlivě otestovali a vše správně fungovalo. Jinými slovy Démosthenés si při testování povídal s Lockem. Nakonec se bohužel ukázalo, že na scéně se skrýval Rochester v podobě implementace rekurzivního resolveru od firmy Nominum, která je při dekódování exponentu velmi striktní a po přijetí klíče novozélandské domény selhala při DNSSEC validaci. Toto nakonec vedlo k tomu, že bylo zapotřebí klíč novozélandské domény opravit a do kořenové zóny poslat klíč ve správném kódování.

Jaké z toho nakonec plyne poučení? Druhá část pravidla robustnosti stále platí, je zapotřebí být velmi striktní při implementaci protokolu, aby byla zajištěna dobrá interoperabilita. Nicméně je jistě ke zvážení, jestli nebýt striktní také při implementaci přijímací části, aby bylo možné odhalit chyby včas již při testování.

A co si myslíte vy? Je lepší být v implementaci striktní nebo liberální?

Ondřej Surý

P.S. Tento článek, respektive odkaz na něj, zahajuje naši komunikaci na Google Plus. Pokud tedy tuto sociální síť využíváte a chcete být informováni o našich projektech a aktivitách, přidejte si nás do svých kruhů.

I-D ECDSA pro SSHFP aneb krátký zápis o vzniku jednoho budoucího RFC…

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ý

KIDNS – Keys In DNS

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:

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ý

DNSSEC klíč v kořenové zóně

Jistě jste si všimli, že vás, naše čtenáře, pravidelně informujeme o dění okolo podpisu kořenové zóny (naposledy zde). Máme za sebou úspěšně první i druhou KSK ceremonii a poslední krok, který dle harmonogramu zbývá, je zveřejnění pravého KSK klíče (až doposud byla kořenová zóna podepsaná pomocí mechanismu DURZ).

A dnešního dne bude celý tento proces, který trval několik měsíců, završen publikováním pravého KSK klíče (teď si na pozadí představte bouchání šampaňského a jásot :)).

Pravý klíč pro kořenovou zónu má následující hash:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkw9t5sACgkQoZmhm3FA9yZfkwCeOo3dGa5Nr1ux4WmDpRIrKjoM
iREAoKtYh03ZK+k5brhikmb+9u5iqOZU
=ZfNp
-----END PGP SIGNATURE-----

Tento DS záznam byl získán z dokumentu, který byl vytisknut na první KSK ceremonii:

Dokument z první KSK ceremonie obsahující DS záznam

DS záznam KSK klíče pro kořenovou zónu je podepsán GPG klíčem CZ.NICu 7140F726, který by měl být podepsán mým osobním klíčem a klíčem CSIRT CZ.NIC. Tento klíč můžete získat například ze server pgp.mit.edu:


gpg --keyserver pgp.mit.edu --recv-key 7140F726

Následující sekce bude platná až po publikaci tohoto klíče do kořenové zóny, která proběhne dnes 15. července 2010 mezi 21.30 – 01.30 středoevropského letního času.

Pokud budete chtít začít validovat pomocí klíče kořenové zóny, tak toto provedete změnou konfigurace vašeho rekurzivního DNS serveru (připomínám, že je zapotřebí rekurzivní server Unbound nebo Bind minimálně ve verzi 9.6-ESV nebo libovolné vyšší).

Přesný popis zveřejnění klíčů naleznete v dokumentu DNSSEC Trust Anchor Publication for the Root Zone. Důležité informace jsou tyto:

Konfiguraci serveru Unbound provedete pomocí direktivy trust-anchor:


trust-anchor: ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"

Druhou variantou je uložení DS záznamu do souboru např. /etc/unbound/root.ds a nastavení directivy trust-anchor-file: (nebo auto-trust-anchor-file:)


trust-anchor-file: "/etc/unbound/root.ds"

Konfiguraci serveru Bind9 je podobná, jen formát záznamu je odlišný. Nepoužívá se přímo DNS záznam, ale rovnou DNSKEY.

Do konfigurace Bind 9.6 vložíte následující blok s konfigurací:


trusted-keys {
"." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};

Konfigurace pro Bind 9.7 je obdobná, ale použije se konfigurační direktiva managed-keys:, která automatickou aktualizaci klíče v případě, že bude DNSSEC klíč změněn mechanismem popsaným v RFC5011:


managed-keys {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};

Po provedení změn musíte znovu načíst konfiguraci a měli byste mít zapnutu validaci pomocí kořenové zóny. Podotýkám, že bych zatím nevypínal validaci pomocí služby ITAR, která v současnosti obsahuje 26 pevných bodů důvěry. Oproti tomu kořenová zóna v čase psaní tohoto blogpostu obsahuje pouhých sedm bezpečných delegací:


# dig @xfr.lax.dns.icann.org . axfr | awk '/^[a-zA-Z0-9-]+\.[[:space:]]/ { print $1, $4; }' | grep DS | sort -u
bg. DS
br. DS
cat. DS
cz. DS
na. DS
tm. DS
uk. DS

Ověření validace můžete například provést takto:


# dig +adflag IN NS . @adresa_vašeho_resolveru

Nyní vypadá výsledek přibližně takto:


$ dig +adflag IN NS . @127.0.0.1

; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
[...seznam NS záznamů...]

;; ADDITIONAL SECTION:
[...seznam IP adres nameserverů...]

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 14 15:45:11 2010
;; MSG SIZE rcvd: 492

Po podpisu kořenové zóny do hlavičky přibude příznak AD:


$ dig +adflag IN NS . @127.0.0.1

; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

[...]

Aktualizováno: Přidána konfigurace pro Bind 9.7.

Ondřej Surý

Další nelatinkové domény v kořenové zóně

Jak jsme vás již informovali, byl doménový prostor rozšířen nejprve o arabské písmo a následně i o azbuku. Domény Egypta (.مصر), Saudské Arábie (.السعودية), Spojených arabských emirátů (.امارات) a Ruska (.рф) jsou již plně funkční v kořenové zóně. Minulý pátek došlo ke schválení dalších dvou písem, konkrétně byly schváleny domény nejvyšší úrovně (TLD) v tradiční a zjednodušené čínštině.

Situace je nejjednodušší v Hongkongu, kde je zápis stejný v tradiční i zjednodušené čínštině – .香港. Tato doménu byla přidělena organizaci Hong Kong Internet Registration Corporation Limited, která dnes spravuje doménu .hk.

Taiwan Network Information Center, správce domény .tw, dostal dvě domény pro Taiwan – .台灣 v tradiční čínštině a .台湾 ve zjednodušené čínštině.

A konečně CNNICu, správci domény .cn, byly přiděleny dvě domény pro Čínu – .中國 v tradiční a .中国 ve zjednodušené čínštině.

Bude zajímavé sledovat, jak se tyto země poperou se situací, kdy lze zapsat stejné slovo dvěma různými písmy. V rámci pracovní skupiny dnsext IETF je ve hře několik návrhů (BNAME, CNAME+DNAME a DNS Shadow), jak celou situaci řešit na technické úrovni, a zatím není rozhodnuto, který z návrhů bude schválen. Zatím to vypadá, že minimálně CNNIC bude generovat zóny se stejným obsahem pro obě varianty písma, resp. dle současných pravidel registrace domény používajících čínské písmo mají vždy 2 – 3 varianty – tradiční, zjednodušenou a volitelně může obsahovat tvar používající obě písma současně.

Ondřej Surý
P.S.: Provedl jsem aktualizaci taiwanských domén na správné tvary. Díky Janu Zahornadskému za podnětnou připomínku.

Facebook na IPv6

Facebook na konferenci Google IPv6 Implementors, která proběhla 10. června 2010 v Mountain View, ohlásil experimentální podporu protokolu IPv6 na dedikované doméně.

Netrpěliví z vás mohou rovnou vyzkoušet následující odkaz: www.v6.facebook.com, který směřuje na IP adresu: 2620:0:1cfe:face:b00c::3 (alespoň ze sítě CZ.NICu). V provozu je také mobilní varianta, kterou naleznete na adrese m.v6.facebook.com.

Z prezentace vyplývá, že Facebook rozběhl dva projekty – Chicago a Cakewalk.

Projekt Chicago měl za úkol beze změn na serverech a s minimálními změnami v produkční síti rozběhnout podporu pro IPv6 protokol. Tato podpora byla implementována pomocí IPv6 load-balanceru, který příchozí provoz na IPv6 adresách rozděluje na IPv4 adresy serverů. Výsledek můžete vidět na již zmíněných URL.

Facebook ale šel dále a v rámci projektu Cakewalk implementoval také podporu pro zbrusu nový protokol LISP (Locator/ID Separation Protocol), který zatím nebyl plně standardizován a je ve stádiu draftů (I-D). Protokol LISP by měl sloužit k rozdělení dvou funkcí, ke kterým nyní slouží IP adresa: a) umístění v síti – tedy jak dostat paket z jednoho místa na druhé, b) identifikátor toho, kdo jste. Nebudu zabíhat do detailů, o tom si můžeme povědět někdy příště.

Každopádně si můžete vyzkoušet i podporu pro protokol LISP a to na adrese: www.lisp6.facebook.com (IPv6 adresa: 2610:d0:face::9). Nicméně vzhledem k tomu, že protokol LISP by měl být transparentní, tak byste neměli pozorovat žádný rozdíl :)

Jen tak mimochodem povšimněte si hříčky se slovem „face“ v IPv6 adrese :-D. Další podobné slovní hříčky v hexadecimálním zápisu jsou k nalezení ve Wikipedii. Do komentářů se pak můžete podělit o nápady, jaké slova se dají zakódovat v češtině a vnést trochu českého humoru do IPv6 adresování. Nejvtipnější IPv6 adresy odměníme malým dárkem (tímto se pasuji na samozvaného a jediného porotce). Konec mikrosoutěže vyhlašuji na letní slunovrat.

Ondřej Surý

Výsledky testování podpisu kořenové zóny

Americký úřad NTIA (obdoba našeho ČTÚ), podobně jako minulý rok při rozhodování zda-li podepsat či nepodepsat kořenovou zónu, vyzval veřejnost, aby komentovali finální zprávu o testování podpisu kořenové zóny.

Tato zpráva byla připravena organizací ICANN a společností VeriSign, tedy hlavními autory současného systému podpisu kořenové zóny, který byl testován. Dokument shrnuje závěry z testování a konstatuje, že při testování nebyly identifikovány žádné škodlivé jevy, které by bránily nasazení systému do produkce. Na základě toho doporučuje pokračovat v implementaci a žádá úřad NTIA o autorizaci.

Rád bych uvedl pár zajímavostí ze zprávy, především v bodech, kde nebyl nahlášen úplný úspěch:

  • Kořenové nameservery sbíraly data z tzv. priming dotazů. Toho sběru dat se nezúčastnil server B.
  • V určitých časových okamžicích probíhal sběr veškerého provozu na kořenové nameservery. Plný sběr dat ze všech nameserverů se povedl pouze u posledních dvou časových oken.
  • Proces testování SKR (Signed Key Response – ruční schvalování klíčů) pověřenou osobou z NTIA nebyl dokončen. V průběhu implementace došlo k zesílení bezpečnosti a pověřená osoba bude SKR autorizovat přihlášením přes certifikát na kartě. Tento proces byl pouze vyzkoušen technickým týmem Verisignu.
  • Nebylo otestováno porušení tzv. tamper pojistky v HSM (Hardware Security Module). Panuje dostatečná důvěra, že tyto testy byly provedeny při certifikaci FIPS 140. Porušením tamper pojistky dochází ke znehodnocení materiálu uvnitř HSM, případně celého HSM.
  • V době publikace této zprávy nebylo dokončeno testování změny DS záznamů. Panuje však shoda, že změna DS záznamů není odlišná od změny jiných záznamů v kořenové zóně a tudíž bude testování úspěšné.

Rád bych na tomto místě a tomto blogu zdůraznil, že celý tým, který měl na starosti odvedl výbornou práci a rád bych tímto poděkoval následujícím lidem:

Joe Abley (ICANN), Mehmet Akcin (ICANN), David Blacka (VeriSign), David Conrad (ICANN), Richard Lamb (ICANN/IANA), Matt Larson (VeriSign), Fredrik Ljunggren (Kirei AB), Dave Knight (ICANN), Tomofumi Okubo (Verisign), Jakob Schlyter (Kirei AB), Duane Wessels (Verisign)

V tuto chvíli zbývá ke spuštění podpisu kořenové zóny už jen pár krůčků. Jedním z nich je vygenerování KSK klíčů, které proběhne příští týden ve středu 16. června 2010 na východním pobřeží (Culpeper, VA). Druhá KSK ceremonie se bude konat 12. července 2010 na západním pobřeží (El Segundo, CA). Následně musí proběhnout oficiální předání DS klíčů mezi TLD operátory a ICANN/IANA. Tento krok bude zatím neviditelný, ale bude zapotřebí, aby ve chvíli spuštění podepsané kořenové zóny do ostrého provozu již kořenová zóna již tyto DS záznamy obsahovala.

Posledním nejdůležitějším krokem bude publikace validních klíčů a správných podpisů, tedy ostré spuštění do produkčního provozu. Tento krok by se měl stát 15. července 2010. A i když mám plnou důvěru k tomu, že vše klapne naprosto hladce, tak stejně držte palce. Jedná se o nejdůležitější změnu v historii v systému DNS od jeho vzniku.

Ondřej Surý

P.S.: Dovolím si na závěr ještě jedno upozornění. Kořenová zóna bude používat algoritmus RSA-SHA256, který je podporován pouze v novějších verzích DNS serveru Bind. Konkrétně 9.6.2-P1 nebo vyšší (nicméně doporučuji nejnovější 9.6-ESV-R1), nebo 9.7.0-P2 (nebo vyšší, v tuto chvíli je již dostupná verze 9.7.1rc1 – tedy kandidát na vydání).

DNSSEC nechutná firewallu ESET Smart Security

Kolegové z provozního oddělení mě upozornili, že narazili na zajímavý problém. V případě, že je v programu ESET Smart Security zapnutý osobní firewall, nefunguje náš doplněk do prohlížeče Mozilla Firefox – DNSSEC Validátor. ESET Smart Security kontroluje obsah DNS zpráv a v případě podezřelého obsahu je taková DNS zpráva zablokována. Bohužel v tomto případě je firewall naprogramován příliš restriktivně a blokuje i naprosto korektní DNS zprávy, které obsahují DNSSEC informace.

Nicméně je velmi pozitivní, a chtěl bych to zdůraznit, že výrobce ESET Smart Security přistoupil k problému velmi zodpovědně a proaktivně; nechal si zaslat blokující komunikaci a v některé z dalších verzí bude tato chyba odstraněna. Kéž by se takto chovali všichni výrobci zařízení, která pracují s DNS.

Mezitím než bude blokování DNSSECu opraveno, můžete jako prozatímní opatření vložit IP adresy DNS serverů do konfigurační volby „Adresy vyloučené z aktivní ochrany IDS“ v editoru pravidel a zón.

Na závěr bych dodal, že při implementaci striktních kontrol libovolného protokolu je zapotřebí sledovat nejen nejběžnější chování tohoto protokolu, ale aktivně vyhledávat informace o možnostech protokolu a také sledovat aktuální vývoj (v případě protokolu DNS to znamená pracovní skupinu dnsext a dnsop organizace IETF).

Ondřej Surý

Publikace podepsané kořenové zóny posunuta

Joe Abley včera informoval komunitu, že se změnily plány podpisu kořenové zóny. Poslední fáze, která obsahuje publikaci kořenové zóny podepsané reálným klíčem, byla posunuta z 1. července 2010 na 15. červenec 2010. Tyto dva týdny budou využity na další studium publikování DURZ (viz úvod) podepsané kořenové zóny.

Dalším naplánovaným krokem k podpisu kořenové zóny bude první ceremonie podpisu klíčů, která proběhne 16. června 2010 v USA ve městě Culpeper. Pro ty z vás, kdo stejně jako já netušíte, kde takový Culpeper leží, tak je to kousek od Washingtonu DC.

Ondřej Surý

Výpadek v .de

Dnes byl cca od 13.30 do 14.50 hodin zaznamenán výpadek v německé TLD doméně .DE. Problematické se ukázaly pouze některé domény – fungovaly pouze ty od písmene A po písmeno F, všechny ostatní se jevily jako neexistující (upřesnění: problém byl někde mezi doménami facebook.de, která fungovala, a ford.de, která nefungovala). DENIC problém dočasně vyřešil publikováním zóny z dnešních 11 hodin, výpadek správce registru dále analyzuje. Budeme kolegům v Německu držet palce, aby vzniklý výpadek rychle vyřešili. Jak se dozvíme více, budeme vás informovat.

Aktualizace z 13. května 2010: DENIC upřesnil čas výpadku. Jmenné servery pro doménu .DE začaly od 12.30 dopoledne přibližně do 14.45 vracet pro zatím blíže neurčený počet doménových jmen odpověď o neexistenci doménového jména (NXDOMAIN). Následně byly chybné jmenné servery buď vypojeny z provozu nebo na nich byl publikován předchozí korektní zónový soubor. Normální chod jmenných serverů byl obnoven v 16.00 hodin.
Čas pro negativní cache je v doméně .DE nastavený na 7 200 sekund, což mohlo způsobit nedostupnost postižených domén přibližně až do 16.45.

Aktualizace z 17. května 2010: DENIC v pátek 14.5.2010 vydal tiskové prohlášení ohledně výpadku doménový jmen v doméně .de. Na části infrastruktury jmenných serverů selhalo finální kopírování zónového souboru a ten se nezkopíroval celý. Bohužel zároveň selhala i kontrola, která měla hlídat, zda-li toto kopírování proběhlo v pořádku. Rád bych na tomto místě také ocenil kolegy z DENICu za velmi otevřený přístup v komunikaci toho výpadku.

Ondřej Surý
P.S.: Díky petr_p za připomínku – chybku jsem opravil.