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ů.

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ý

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

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:

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:

• Klíč bude zveřejněn ve dvou formátech:
  • v XML obsahující hash DNSKEY klíče ve formátu DS záznamu
  • v CSR (Certificate Signing Request) ve formátu PKCS#10
• URL XML souboru bude: https://data.iana.org/root-anchors/root-anchors.xml
• Podpisy souboru trust-anchors budou uloženy v:
  • S/MIME: https://data.iana.org/root-anchors/root-anchors.p7s
  • OpenPGP: https://data.iana.org/root-anchors/root-anchors.asc

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

;; 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

[...]


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

Ondřej Surý