Názory k článku
Ondřej Filip, CZ.NIC: OpenID ještě nikdo nechytil za správný konec

add DNSSEC: chvála
add diakritika v doménách: pokud se to nedejbože jednou prosadí, budete dál dělat pravidelnou anketu pro jejich zrušení? (asi ne)
Pokud je využití 1% domén, nemá cenu to zavádět.
Kdybyste to zavedli jako službu (placenou či zdarma) k existujícím doménám (nešlo by oddělit DNS záznamy pro zíve.cz, živě.cz, živé.cz a zive.cz), tak by takový odpor nebyl.
add OpenID: těším se a doufám, že se mojeID.cz povede. Už má ale trochu skluz, původně tam byl snad uveden nějaký měsíc, co už je fuč.

Problém není jen v zaregistrování různých variant k doméně bez diakritiky, aby je někdo nezneužil, ale hlavně v tom, že díky použití UTF kódování lze vizuálně zaměnit znaky s naprosto jiným významem, což výrazně nahrává podvodným stránkám, které mohou získat i certifikát, a tak snadněji obelstít svou oběť. IDN je omyl a u nás nemá opodstatnění, respektive nevýhody převažují nad výhodami.
Co se týká OpenID, tak to bych uvítal hlavně u registrace do diskuzí, jejichž registrace je na některých serverech tak komplikovaná, že mi to za to ani nestojí.

Toto bylo probíráno už snad miliónkrát, takže po miliónté a prvé:
Registrátor nepovolí mixování znakových sad (v případě generických domén) nebo použití jiné než národní znakové sady (např. v .cz nepůjde registrovat doména v azbuce).

Ano? A co zabrání zfixlovat suffix CZ, nebo jiný?

Že by ICANN?

Proč myslíte, že Rusko nedostalo IDN doménu .PU, ale РФ? :)

Dáte za to hlavu na špalek? Za to, že nebudou registrované dva různé znaky se stejným visuálním zobrazením?

Pamatuju, kdy se v CZ doméně nesmělo registrovat slovo obecného významu.

No.. je to vaše hlava, ale já bych to al nedělal.

No to jsou argumenty. Taky na nás může za pět minut spadnout meteorit (to už se před 65 miliony let taky stalo!) nebo tu vybuchne jaderná bomba (to jsem dokonce zažil! tedy, byl jsem několik tisíc kilometrů daleko…).
Možnost registrace obecných slov nepředstavuje bezpečnostní riziko, dopady registrace graficky shodných znaků z jiných abeced si dokáže představit kde kdo.

1. že jsou pravidla, která lze obejít (viz obecná slova, který šla obejít)
2. graficky zaměnitelná interpretace znaků bezpečnostní a hospodářský problém je a nemá v současném stavu uspokojivé řešení
3. přehazovat problém na uživatele dělá jen diletant

1. Nevím, jak šla obejít registrace obecných slov (tuším založením firmy s obecným názvem?) a netuším, jak by šlo obejít to, že CZ.NIC prohlásí, že .cz domény mohou obsahovat jen znaky [a-z][0–9]-ěščřžýáíéúůďťň (a možná ještě ü – jméno Müller) a žádné jiné prostě nepovolí.
2. Problém to je, to připouštím, a řešení má – prostě se nepovolí mixování abeced v rámci jedné domény, případně se povolí pouze národní znaky (u národních TLD).
3. Kdo přehazuje problém na uživatele?

ó
Böhm

Dobry den,
dekuji za dotazy. K tomu IDN muzu jen rict, ze udelat IDN varianty tak, aby byly zcela ekvivalentni s puvodnimi DNS zaznamy neni uplne jednoduche. V soucasne dobe se v IETF toto tema diskutuje. My prosazujeme umozneni CNAME i DNAME najednou, ale diskutuje se i o jinych navrzich. Mnohem urgentnejsi potrebu takoveho reseni maji predevsim lide z Cinskeho registru. Maji 2 domeny v cinskych znacich pro Cinu a potrebovali by, aby registrace v obou techto DNS stromech byly zcela ekvivalentni.
OpenID skluz nema, jede presne podle puvodnich planu. V puvodnim dokumentu byl uveden rijen 2010.

Ja si nemyslim, ze by stavajici OpenID neresilo zadnej problem. Pro provozovatele webu to mozna zadna velka bomba neni, ale z pohledu uzivatele to problem centralniho prihlasovani resi velmi dobre. Teda resilo by, pokud by se s tim dalo nekde prihlasit. ;) Kazdej kdo mohl, rozjel providera, ale na consumera narazim velmi zridka.
U mojeID mi neni jasna jedna vec. Kdyz se poskytovatel webu necha ukecat na jeho podporu, bude tim automaticky podporovat jakykoliv obecny OpenID, nebo jen to „jediny spravny“ mojeID?

„U mojeID mi neni jasna jedna vec. Kdyz se poskytovatel webu necha ukecat na jeho podporu, bude tim automaticky podporovat jakykoliv obecny OpenID, nebo jen to „jediny spravny“ mojeID?“
Bude se moct rozhodnout – podle toho, jestli bude požadovat alespoň základní ověření (SMS, snailpost), povolí jen „důvěryhodné“ oID providery, pokud mu stačí jenom identifikace, povolí všechny.

Kdo nechce anonymitu nebo je mu to jedno už je na na „Libku“, „FCKbuku“ a jiných „ehm“ službách. Opatrní, zlé jazyky je nazývají paranoici (proč jako, neopatrných hazardérů je na hřbitovech s pomníčky okolo cest spousta), se stejně nebudou „odanonymizovávat“.

Ale no tak :-). Považuji se za paranoika, ale zrovna spojování mých příspěvků na Internetu mi nevadí – když to vystavuji na veřejné místo… Ale chápu, že někomu by to vadit mohlo (např. spojování názoru s firmou, ve které je zaměstnaný).
Ale je otázkou, za jak dlouho si pro mě přijedou kvůli mým komentářům o bezpečnosti a neustálého rýpání do Datových sránek a státu obecně :-).

Chtěl bych se zeptat, zda bude možno nahrát si do (ověřeného) mojeID profilu veřejný PGP klíč, případně zda plánujete i PGP klíče podepisovat.

Proč bych měl publikovat svůj veřejný PGP klíč ověřený OpenID providerem, když můžu publikovat veřejný RSA klíč jak součást svého X.509 certifikátu podepsaného certifikační autoritou? Plýtvat omezenými zdroji CZ.NIC na reimplementaci PKI mi nepřipadá jako dobrý nápad…

Problém neanymního pobytu na internetu vidím v tom, že vše může být zálohováno na věčnost. Jenže lidé se mění. Takže vězte, že by mi opravdu bylo nepříjemné, kdyby na mě někdo vytáhl, co jsem dělal na internetu před 15 lety!
Nick se dá změnit. Reálné jméno obtížně.
A druhý problém je v tom, když se heslo prozradí. Když mám různá hesla do různých služeb, tak jsem docela v pohodě, ale když mám jediné heslo na všechno, tak jsem v neuvěřitelném průseru!

tak si to jedno heslo změníš a dokonce na jednom místě, a je to. :-) Teda pokud si ho nezmění někdo za tebe.

Nevím jak ty, ale jak rychle to asi tak stihnu? Někdy taky spím, nebo jsem na bezinternetové dovolené či víkendu.
Kdyby útočník hodinu řádil na všech mých účtech, tak jsem totálně v koncích!

To je problém, který se řeší bezpečnostním tokenem.

>> Protože to nikdo ještě nevzal za ten konec, za který to bereme my.
To se mi líbilo, sebevědomí je potřeba! :)

Připravuje nic.cz automatickou kontrolu DNS záznamů? Kontrola by měla být pravidelná s tím, že v případě problémů by se poslalo upozornění technickým kontaktům domény. Tuto kontrolu provozuje např. švédský registrátor na http://dnscheck.iis.se/, bylo by to velmi vhodné i pro české domény.
Dle logů našeho validujícího nameserveru mají chybně implementovaný DNSSEC (tj. uživatelům jsou nedostupné) domény epizoda.cz, kad.cz, kinoteka.cz, filmacek.cz, rempo-eshop.cz, autosklo-perfekt.cz a další. Ve většině případů je DS záznam v zóně .cz, ale chybí klíč DNSKEY ve vlastní zóně.

Jenom technický dotaz – jak si mohu nastavit hloubku kontrol?

Stejně jako všechny ostatní parametry nastavení – přes svého registrátora.

Zrovna u Web4U je problem, ze oni podporuji DNSSEC jen u domen, ktere jsou na jejich vlastnich nameserverech. Pokud mate svoje nameservery, neni moznost nijak pres Web4U do zony .cz dostat svoje DS zaznamy (ale pry to behem letoska zprovozni, abych jim zase nekrivdil). Kazdopadne situace neni az tak vesela jak jsem si myslel.

Dobry den, predpokladame, ze sprava keysetu vcetne moznosti prirazeni k domene bude zprovoznena pro zakazniky do konce srpna.
Michal Adamek, Web4U s.r.o.

Alternativa k OpenID:
http://www.easylogin.net

Ach, ta Praha..
„…i tématy, kterÁ zajímají českého uživatele internetu.“ je česky :-).

Kdyz jsme u pravopisu – „…tak informace od něj ke mě jdou bez podpisu…“

Rád bych se zeptal na jednu věc související s DNSSEC. Existuje možnost do DNS uložit např. veřejný klíč k SSH serveru, lze uvažovat i o certifikátu pro SSL resp. možnosti takto „nahradit“ důvěru v certifikační autority důvěrou v podpis kořenové zóny. Tyto možnosti byly diskutovány už u předchozích článků na téma DNSSEC.
Jsou známé nedostatky současného modelu využívání SSL, kdy aplikace typu webový prohlížec implicitně důvěřují množství certifikačních autorit, kde o některých lze mít pochybnosti. Pro realizaci MITM útoku stačí získat certifikát pro danou doménu od libovlné implicitně důvěryhodné CA. Uvážíme-li, že MITM útok bude veden např. státními orgány v rámci „využívání operativní techniky“, není taková představa zcela nereálná.
Lze využít DNNSEC takovým způsobem, že důvěryhodnost zjištěných DNS záznamů bude pro koncové zařízení (s vlastním rekurzivním resolverem) nezpochybnitelná, leda že by na změně spolupracoval správce TLD nebo kořenové zóny?
Jinými slovy, dnes útočníkovi na SSL spojení stačí opatřit si certifikát pro danou doménu od kterékoliv „běžně důvěryhodné“ CA. Majitel dané domény nemá šanci takový útok zjistit. Dává DNSSEC, označovaná někdy jako globální PKI, v tomto směru lepší možnosti? Z vlastní úvahy mi vyplývá, že ano, a že pro analogii naznačeného útoku by byla třeba aktivní spolupráce držitele klíče, jímž byla podepsána doména, nebo správce TLD, což ovšem může držitel domény detekovat jako změnu veřejného klíče v registru.
Poskytnutí klíčů ke kořenové zóně státním orgánům např. ve jménu boje proti terorismu je vzhledem k velmi pěkně popsané proceduře předpokládám nereálné. A to je dobře.

DNS (DNSSEC) pokud vim zadny specialni zaznam pro neco takoveho nema, ale nevidim duvod proc nepouzit stavajici typy zaznamu (SRV,TXT..), problem ovsem je, ze pokud vim, zatim neexistuje zadny standard (domluva) jak takovou informaci „ukladat“, takze „klient a server“ se nemaji jak domluvit…
Napad je to ale dobry takze zkuste neco navrhout (RFC) ;)

RR záznam pojmenovaný SSHFP definuje RFC4255[1], pro vytvoření samotného obsahu záznamu můžete použít sshfp[2][3] v Linuxu. Nicméně jeho použití musíte v OpenSSH zapnout.
Pro TLS:
Zrovna dneska v noci byl konečně na IETF založen mailinglist, o který jsem žádal: KEYASSURE [4]. Na BoF (Bird of Feather) na IETF v Maastrichtu bylo asi 50 lidí, kteří se o toto téma zajímali a přibližně půlka se přihlásila, že by chtěla být v tomto směru aktivní.
TLSFP + DNSSEC budou umožňovat dvě věci (zjednodušeně):
1. Použít self-signed certifikát
2. Použít libovolný certifikát (např. EV) a říci, že musí být použit pouze ten.
Jinak již vznikl první internetový draft (I-D)[5], které bude základem práce pro KEYASSURE. Více pak je (a teprve bude) v archivu konference.
O.S.
P.S.: Mimochodem podobný standard existuje pro IPSec[6].
Odkazy:
1. http://tools.ietf.org/html/rfc4255
2. http://www.xelerance.com/software/sshfp/
3. http://packages.debian.org/sshfp
4. https://www.ietf.org/mailman/listinfo/keyassure
5. http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt
6. http://tools.ietf.org/html/rfc4025

Výborně. Děkuji za podrobné vysvětlení.
2. Použít libovolný certifikát (např. EV) a říci, že musí být použit pouze ten.
Dejme tomu, že na tohle vznikne nějaké rozšíření do Firefoxu, a které než se to vyřeší systémově, bude samo posílat DNS dotazy.
A mě právě zajímá, jestli exituje možnost, aby nějaký útočník s přístupem k routeru skrze který jde TCP spojení, tuto informaci „musí být použit pouze ten“ byl schopen odfiltrovat, aniž by se to poznalo. Resp. co by musel udělat a kam jinam by musel mít přístup. Stejně jako když se dnes někomu podaří nechat si vystavit důvěryhodný certifikát pro cizí doménu, může ho použít aniž by si uživatel něčeho všiml.

Pokud se u podepsané domény zeptáte na CERT (nebo TLSFP), tak musíte dostat podepsanou odpověď (NSEC/NSEC3), jinak se musíte chovat, že došlo k podvržení (stav bogus).
Jinak Adam Langley z Google už má funkční kód experimentálního prototypu v Google Chrome. Je to sice takový trochu bastl kvůli tomu, že balí celý DNSSEC chain do rozšíření v certifikátů, takže to vlastně nemá s DNS nic moc společného (kromě společného klíče), ale jako startovací experimentální metoda by to mohlo fungovat.
Cílem KEYASSURE (snad vznikne IETF WG) bude specifikovat finální protokol, resp. spíše sadu finálních protokolů. Je tam pořád spousta nedořešených věcí (hlavně zabezpečení last mile).
Jinak pokud Vás to zajímá, tak se do mailing listu přihlašte… :-)

zdravim,
OpenID nejde chytit za zadny spravny konec.
Nejake duvody:
- protoze urad pro ochranu osobnich udaju.
- staci vzit za spravny konec klientske certifikaty, ale to uz se povedlo v tomto state vcelku znicit. A jejich instalace pro uzivatele neni take zcela jednoducha.
- je sice pekne, ze mi se mi nekdo prihlasi pomoci openid, ale jak mu treba poslu zasifrovany email „podepsany pres neco z OpenID“…
- OpenID je dobre tak akorat na web. A tim to konci. To bych videl jako zakladni nedostatek.
Nepreji Vam nic spatneho a ani nepochybuji o Vasich schopnostech. Ale domnivam se, ze prevratne technologie jsou uz spise ty vymyslene a je to jen o jejich aplikaci.
gf

Na svůj blog jsem sepsal základní informace o MojeID: http://www.jiri-kolarik.cz/clanek/jak-na-mojeid-predstaveni/