Důležitou podmínkou založení pracovní skupiny je, abyste měli dostatek lidí, kteří budou ochotni v dané pracovní skupině pracovat na standardech, jejich revizích, atp. Nutnou, nikoli postačující podmínkou většinou bývá mít zajímavé téma, které přiláká dostatečný počet lidí. Pokud tedy máte téma, tak se většinou postupuje tak, že se uspořádá neformální setkání na IETF meetingu, kterému se říká BoF. BoF je zkratka z anglického Birds of a Feather, které pochází z přísloví, které bychom mohli do češtiny volně přeložit jako „Vrána k vráně sedá“ (Birds of feather flock together). Toto setkání může mít dvě formy – oficiální BoF, který musí projít schválením ředitele oblasti (AD), a neformální bar BoF.
Cílem oficiálního setkání je ujasnit si, zda existuje dostatečný počet „vran“, které se sejdou v pracovní skupině, a také jestli existuje alespoň přibližná shoda v názorech, kam by se taková pracovní skupina měla ubírat. Pokud BoF dopadne úspěšně, tak se budoucí pracovní skupina shodne (pamatujete – hrubý konsenzus) na stanovách a potom už je jen krůček ke schválení a založení oficiální pracovní skupiny.
Druhá forma setkání je neformální bar BoF, který se většinou koná, jak už vyplývá z názvu, v podvečerních hodinách někde v baru, kde se sejde pár lidí, kteří mají o téma zájem. Někdy se ovšem bar BoF může zvrhnout a počet účastníků je větší než počet míst v přilehlém baru a v takovém případě se bar BoF sice koná po skončení oficiální programu IETF meetingu, ale jsou pro něj využity normální konferenční prostory.
Ale jak se říká, šedivá je teorie, zelený je strom života, takže se pojďme podívat na vznik jedné konkrétní pracovní skupiny. Na počátku byl nápad, který jsme v CZ.NICu dostali před nějakou dobou, když jsme přemýšleli, jak se svět DNS změnil po implementaci zabezpečení DNSSEC. Samotný systém DNS je moc pěkná distribuovaná a hierarchická databáze. S příchodem DNSSECu navíc vznikla možnost mít tuto databázi i zabezpečenou. A pokud se bavíme o zabezpečení, tak se logicky dostáváme do oblasti zabezpečení samotných spojení, které je nejčastěji realizované pomocí protokolu TLS (resp. většinou známé pod názvem SSL, což je původní název předchozích verzí protokolu). Zjednodušeně řečeno je současný model TLS založen na hromádce certifikačních autorit, které máte nainstalovány ve svém počítači (v případě Windows 7 už není pravda ani to, certifikáty certifikačních autorit se stahují na požádání přes Internet). Všechny tyto certifikační autority mají stejnou (tedy v podstatě absolutní) důvěru, což není zrovna dobrý model, protože se nedá předpokládat, že všechny certifikační autority jsou na tom s úrovní bezpečnosti také na stejně vysoké úrovni. Jinými slovy celá bezpečnost modelu postaveném na mnoha certifikačních autoritách je tak bezpečná jako nejméně zabezpečená certifikační autorita, což v případě DV (Domain Validated) certifikátů je na úrovni ověření toho, zda jste schopni číst poštu příslušející k dané doméně.
Jistě vám již dochází, že onen nápad byl uložit do té pěkné distribuované, hierarchické a nyní i zabezpečené databáze zvané DNS informaci o certifikátu, který je příslušný k daném doménovému jménu. Tento nápad v sobě slučuje dvě možnosti vylepšení současného stavu zabezpečení. První možnost, která se tímto otevřela, je začít používat self-signed certifikáty (tedy ty, které nevydala žádná oficiální certifikační autorita) bez onoho „otravného“ okna, které vyskočí v prohlížeči a které stejně většina normálního uživatelů odklikne. Druhá možnost zvyšuje bezpečnost u všech certifikátů tím, že umožní majiteli domény říci: „Chci používat pouze tento certifikát a žádný jiný.“
S tímto nápadem jsme přišli do pracovní skupiny DNSEXT, kde jsme podali návrh na registraci nového RR typu pracovně nazvaného TLSFP. Tento zrychlený návrh na registraci nového RR typu bohužel neprošel a vznikl požadavek na kompletní návrh specifikace. Také se ukázalo, že jsme nebyli první, kdo s podobným návrhem přišel. Bohužel však většina dřívějších návrhů nebyla vůbec schválena nebo v případě RR typu CERT upadla v zapomnění. Zpětně je vidět, že pro tyto návrhy nebyla vhodná doba, protože DNS nebylo zabezpečené.
Situace se změnila s podpisem kořenové zóny minulý rok, kdy se téma ukládání certifikátů do DNS opět začínalo diskutovat v různých poštovních konferencích, a hrozilo velké roztříštění vývoje, kdy by došlo k více nezávislým vzájemně nekompatibilním implementacím. Tuto hrozbu se nám naštěstí v podstatě povedlo zažehnat tím, že jsme na loňském IETF setkání v Maastrichtu v roce 2010 uspořádali bar BoF. Jak jsem zmiňoval již na začátku, tak na onen bar BoF, který by se původně měl odehrávat nad sklenicí piva, přišlo místo pár lidí, kteří by se vešli k jednomu stolu, celkem přes padesát až šedesát účastníků, kteří aktivně diskutovali a také byli ochotni aktivně pracovat na tématu v rámci budoucí pracovní skupiny.
Taková hojná účast potvrdila zájem o toto téma a ještě v Maastrichtu jsem se domluvil s Warrenem Kumarim ze společnosti Google, že začneme pracovat na založení pracovní skupiny. Jen o pár dní později jsme oslovili ředitele oblasti Security a dohodli jsme se, že nám pomůže založit e-mailovou konferenci, kterou jsme nazvali keyassure. Historicky první uvítací zprávu do konference zaslal Warren 17. srpna 2010 a od té doby bylo do konference posláno přes 1500 příspěvků.
Současně se schválením jsme společně s Warrenem začali připravovat stanovy pracovní skupiny. Nad stanovami se mnohdy bouřlivě diskutovalo, ale nakonec jsme dospěli k výsledné podobě, která byla přijatelná pro většinu účastníků, takže přibližně v době, kdy se žádalo o přidělení časových oken na dalším IETF meetingu, který proběhla na podzim 2010 v Pekingu, jsme měli více méně finální verzi.
Na tomto místě bych poznamenal, že pro založení nové pracovní skupiny již není zapotřebí, aby se konalo oficiální BoF setkání, ale v našem případě to bylo přání IESG, aby se ukázala životaschopnost skupiny. Osobně musím říct, že účast na BoF v Pekingu předčila mé očekávání. Na seznam účastníků se zapsalo více než 130 lidí a vyčerpali jsme skoro celé dvě hodiny, které jsme měli na setkání vyhrazeny.
Zde bych měl jednu poznámku na okraj. Pokud se podíváte na seznam pracovních skupin, tak je vidět, že volba vhodného názvu pracovní skupiny je velmi důležitá, protože mnohé z nich mají vtipný název, který vznikl jako zkratka slov, které nějakým způsobem popisují náplň práce WG (kitten – koťátko, drinks – nápoje, atp.). Nebylo tomu jinak ani v případě naší pracovní skupiny, kde jsme z názvu keyassure přešli na název kidns (Keys In DNS, ale také se název dal vyslovovat jako anglické slovo pro ledviny). Pod názvem kidns se konal BoF v Pekingu. Bohužel názor IESG byl, že se tento název až příliš podobá výše zmíněnému koťátku a pracovní skupiny by se mohly plést, tudíž jsme byli nuceni finální název změnit na DANE, což v angličtině kromě Dána také znamená německá doga (Great Dane).
Samotnému schválení pracovní skupiny předcházelo několik konferenčních hovorů s řediteli oblasti Bezpečnost (Security Area) a opravdu si musím pochválit, že oba ředitelé byli více než nápomocni vytvoření naší pracovní skupiny. Finální posvěcení ze strany IESG jsme dostali 10. prosince 2010, kdy vznikla nová pracovní skupina DANE WG (zde naleznete i stanovy).
Na závěr bych rád uvedl, že není zapotřebí se IETF bát. Některé věci trvají možná déle, protože je vždy zapotřebí dosáhnout alespoň hrubého konsenzu, ale nakonec zjistíte, že celý proces funguje efektivně a v rámci možností i rychle. Takže pokud vás zajímá svět internetových standardů, nebojíte se trošky byrokracie a dokážete pod tíhou argumentů změnit názor, jste více než srdečně zváni se zapojit nejen do nové pracovní skupiny DANE, ale také do práce celého IETF, a to třeba tak, že přijdete na příští IETF meeting, který bude v Praze a hostí jej CZ.NIC.
ČLÁNKY DO MAILU