Kilka dni temu odbyło się w Brukseli spotkanie przedstawicieli Komisji Europejskiej, rzadów i zaproszonych ekspertów. Spotkanie to poświęcone było rozwiązaniom DNSSEC, a więc „bezpiecznej” wersji protokołu DNS. Osoby zainteresowane tym, co to jest DNSSEC, odsyłam do bogatych źródeł w Internecie. Wystarczy wpisać w Google frazę „DNSSEC”.

Ale wracając do spotkania w Brukseli, w przeciwieństwie do ICANN-u i przedstawicieli (byłej) administracji amerykańskiej (byłej, bo co do obecnej to nikt nie wie, jakie ma stanowisko w tym zakresie), Komisja Europejska chce faktycznie temat poznać, i dopiero mając odpowiednią wiedzę, zająć stanowisko. 

Bardzo rozsądne podejście. Spotkanie miało na celu właśnie edukację i poznanie poglądów zarówno zwolenników, jak i przeciwników DNSSEC. Zaproszeni przez KE eksperci to przedstawiciele rejestrów UK, CZ, SE, AT, DE oraz moja skromna osoba z PL. Na spotkaniu byli też przedstawiciele ICANN-u oraz firm zajmujących się bezpieczeństwem DNS, m.in. CommunityDNS oraz Autonomica. 

Spotkanie nie zakończyło się konkretnymi wnioskami – to zadanie samej Komisji, aby podjąć własną decyzję w tej sprawie i wziąć za to odpowiedzialność. Jednak główne argumenty, które na spotkaniu padły, a które na chwilę obecną nie pozwalają na wdrożenie DNSSEC w praktyce, to:

• NSEC3 (implementacja DNSSEC) jest produktem świeżym, nie został wystarczająco przetestowany; w rezultacie nie może zostać zastosowany tam, gdzie jest wymagana niezawodność np. w domenach narodowych.
  
• Brak ustandaryzowanej w IETF procedury zarządzania kluczami i podpisywania plików stref na poziomie root – obecnie próbuje się na siłę znaleźć rozwiązanie tego problemu w postaci bazy Trust Anchor Repository oraz koncepcji kluczy współdzielonych pomiędzy różne instytucje itd.Warto dodać, że proces standaryzacji DNSSEC trwał 15 lat, a mimo to procesy obsługi kluczy na poziomie root nie zostały zdefiniowane – amatorstwo jakich mało. 
  
• Jeśli baza centralna (Trust Anchory Repository) będzie w pewnym momencie nieosiągalna, to użytkownicy Internetu otrzymaja dla domen podpisanych cyfrowo komunikat, że dane domeny są nieprawidłowe i strona nie może zostać załadowana mimo tego, że sama domena i DNS będą funkcjonowały bez zarzutu.
  
• Brakuje określonych (wystandaryzowanych) sposobów zachowania plikacji w sytuacji kiedy: nie można dokonać weryfikacji podpisu bądź weryfikacja zakończyła się negatywnie. 
  
• Na chwilę obecną DNSSEC nie zapewnia bezpiecznej drogi pomiędzy drzewem DNS a użytkownikiem końcowym – nadal brakuje np. systemów operacyjnych wspierających DNSSEC; Windows 7 będzie wspierał DNSSEC, ale tylko w wersji Server, o desktopach na razie nikt nie myśli, bo i tak nie ma na to klientów.
  
• DNSSEC to niestety porażka biznesowa w krajach, które zdecydowały się wdrożyć tą technologię – pytanie czy w Polsce ktoś odważyłby się wydać pieniądze na coś co zadowoli kilkustet użytkowników? Może największe firmy jak Home czy NetArt, ale i tak w to wątpię.
  
• Skomplikowany proces generowania kluczy i obsługi podpisywania stref spowoduje, że zamiast użytkownika (abonenta domeny) będzie to realizowane przez Registrara (Partnera). Opisane podejście mija się z celem, bo poziom zaufania do takich domen automatycznie maleje. 
  
• Konkurencja w postaci SSL dobija DNSSEC. SSL pozwala nie tylko zabezpieczyć stronę, ale również poprzez np. extended validation, zapewnić wysoki poziom autentykacji kto jest właścicielem serwisu. Niestety DNSSEC nigdy nie zapewni autentykacji. Przykładowo jeśli ktoś nieuprawniony zarejestruje powiedzmy citibank.XX to na podstawie certyfikatów SSL będzie można sprawdzić czy taka strona faktycznie należy do Citibank. Ale w przypadku DNSSEC otrzymamy niestety np. odpowiedź potwierdzającą, że dane skojarzone z domeną należą do firmy która domenę zarejestrowała – ale czy to jest Citibank czy nie, tego się nie dowiemy, a nieświadomy użytkownik uzna, że strona jest autentyczna i... phishing gotowy. 

Strona tego bloga