Uudised, sündmused ja blogi

ICANN78 - kas DNSSEC on läbi kukkunud?

Enne aga… Rootsi register tõstatas turvaliste turvakoodide küsimuse. Turvakoodid on autoriseerimiskoodid, mida rakendatakse registripidaja vahetusel. Probleemideks on koodide nõrkus, nende taaskasutamine, talletamine ja kaitsmine, koodide mitte aegumine ning ebaturvaline edastamine. Selle kõigega kaasneb risk domeeni kaaperdamiseks. Riikide registrid rakendavad erinevaid praktikaid – näiteks võimaldatavad mõned neid määrata ja hallata registreerijatel endil, mis ilma parooli tugevuse reegliteta päädib aga massilise nõrkade paroolide taaskasutamisega. Taanlased on seevastu loonud ajutise koodi funktsiooni - kood genereeritakse siis, kui selleks on tekkinud vajadus. Koodi genereerib domeeni registripidaja, mis eeldab tema osalemist üleviimise protsessis ja pole seega väga hea lahendus. Parema tulemuse saavutaks, kui vastuvõttev registripidaja algatab domeeni ületoomise, mille tulemusena luuaks registris ülekande kood, tehakse see registreerijale kättesaadavaks ning kes seejärel peab koodi edastama registripidajale. Lõpplahendusena ei luba rootslased enam registripidajail koode luua, genereeritakse tugevad koodid vastavalt süsteemis seatud reeglitele ning paroolid aeguvad ja genereeritakse automaatselt uuesti.

Ideena kasutakse võimalust luua registreerija korraldusel lühikese kehtivusajaga paroole registreerija portaalis. Kasutaja vajutab näiteks "kopeeri kood" nuppu, mille tulemusena luuakse kood ja kopeeritakse registripidajale edastamiseks lõikelauale.

Meil pole registripidaja vahetusega seni probleeme olnud ja ei oska siin suurt probleemi näha - registripidaja vahetust ei loe me kriitiliseks operatsiooniks, sest registreeringu omaniku andmed ei muutu ning kui mõni meie akrediteeritud registripdijatest võimaldab kontrollimata/autoriseerimata omaniku vahetust, on probleem hoopis mujal ja see on oluliselt suurem.

EURid (.eu) tutvustas taas oma katsetusi AI vallas. Töös on 3 lahendust - kuritarvitamise ennetamise lahendus registreerimisel; automaatne veebilehtede klassifitseerija; domeeninimede generaator. Kuritarvituste ennetaja on esmane filter, mille kaudu tuvastatakse kahtlaseid registreeringuid ning mis suunatakse edasi registreerija isiku tuvastamise kontrolli ja jagatakse täiendavalt küberturbe partneritega edasiseks uurimiseks. EURid on tulemustega väga rahul - tuvastatud kuritarvituste arv on langenud pea 70%. WebClass on .eu mitmekeelne veebilehtede klassifitseerija. Hea tulemuse saavutamiseks on vaja väga palju treeninginfot - selle raames teevat nad koostööd CENTRiga. Ka sellel on head tulemused - varem tegeles klassifitseerimisega inimene, kellel kulus 10000 domeeni peale 1 kuu. Masin teeb selle ära 1 tunniga ning tulemus on varasemaga võrreldes ka täpsem. EURid võrdles oma mudeli tulemusi ka ChatGPT ja Google klassifikaatoriga - ChatGPT 62%, inimene 66%, Google 80% ning .eu mudel 86%. Viimasena näidati taas juba kevadel Jamboreel esitletud domeeninime generaatorit. See töötab vestlusroboti stiilis domeeninime soovitajana - kasutaja sisestab kirjelduse oma vajadusest või äriideest ja ChatGPT soovitab siis sobilikke nimesid. Kõik soovitused lastakse enne läbi ka kontrollist, et need oleksid vabad. Kokkuvõttes on EURid AI-usku register.

ICANNis tegeletakse EPP laiendusega DNSi TTLi määramiseks. Erinevad registrid rakendavad väga erinevaid TTL väärtuseid tunnist kuni päevadeni. Pikk periood tähendab pikka perioodi ka andmete uuendamisel. Register määrab täna ise väärtuse - registripidajad, dns operaatorid ja registreerijad ei oma selle üle kontrolli. Eesmärk on anda kontroll registripidajale, kes saab siis ise TTLi määrata. Standardi kallal töö alles käib: draft-ietf-regext-epp-ttl-02.

deSEC on mittetulunduslik organisatsioon, kes teeb DNSSECiga sama, mida Let’s Encrypt TLSiga ehk  pakutavad tasuta DNSSECi ja DANE teenust oma klientidele. Nad viisid huljuti läbi kampaania DNSSECi olukorra parandamiseks oma klientide seas saates pöördumise kõigile, kelle puhul oli vanemtsoonis DS kirje puudu. Kampaania kestis 2 nädalat - esimene pöördumine, nädal hiljem meeldetuletus ning kahe nädala lõppedes koostati tulemused. Tulemuseks korrektselt DNSSECitud tsoonide protsendi paranemine 9 võrra 66%ni, väga suur osa kliente ei reageerinudki teadetele ning  ligi 80% registreerinutest vajasid abi. Kokkuvõttes leidsin, et kliendid suhtusid üldiselt positiivselt läbi viidud kampaaniasse, mis oli üks väheseid positiivseid signaale DNSSECi suunas sel ICANNil. Teine, ehk isegi loogiline järeldus kampaaniast oli DNSSECi automatiseerimise positiivsest mõjust, mis oleks toe koormust vähendanud 80% võrra. Kahjuks on täna vaid üksikud TLDd, kes seda toetavad.

SSAC parasjagu automatiseerimise teemaga tegelebki. Töögrupis toimus põnev arutelu, kas DNSSEC ja DNSSECi automatiseerimine CSYNC/CDS mehhanismi läbi peaks olema selle grupi ametlik soovitus. Automatiseerimine teeb DNSSECi kasutusele võtmise mõneti lihtsamaks eemaldades osa halduskoormusest DNS teenuse pakkujatelt ja registripidajatelt - aga mitte täielikult. CDS standard näiteks ei käsitle race-condition olukordi. Õhku jäi küsimus, kas automatiseerimise lahendused mitte ei tekita selles osas probleeme juurde või on need olemas hoolimata sellest tehnoloogiast? Eraldi küsimus on, et kas SSAC peaks soovitama tehnoloogiaid, mida turg ei taha - CSYNC on olnud olemas juba aastaid, kuid selle kasutatavus on vähene, andes mõista, et selle järgi puudub vajadus. CDS ei ole halb, aga kas on õige võtta see ette soovitusena ICANNile ja kogukonnale ning seeläbi sisuliselt muuta see rangelt soovitatavaks kõigi gTLDde jaoks?

DNSSEC on kasulik ja toimiv tehnoloogia, kuid see on keeruline, haldus kulukas ning sellega kaasnevad olulised riskid. Samal ajal ei hooli interneti kasutajad suuremast osast probleemidest, mida DNSSEC lahendab. Kasutajatele läheb korda, et aadress, kuhu nad pöörduvad, on see, kuhu nad jõuda tahtsid. DNSSEC seda ei valideeri, küll teeb seda aga TLS. DNSSEC on olnud saadaval 2005 aastast. Tänaseks on kõik gTLDd allkirjastatud pea kõikide ccTLDde poolt. Aga domeenid ise ei ole. Erinevatel hinnangutel on alla 10% olulisematest domeenidest üle kogu maailma DNSSECiga kaitstud. Teine pool võrrandist on võimekus DNSSECi võtmeid ja ahelat kontrollida. Valideerimise ülemaailmne keskmine on 30,5% ning 8,5% valideerib seda osaliselt.

DNSSECiga kaaneb oluline risk - kui teed ahela katki, siis on kasutajate jaoks kättesaamatu nii domeen ise kui ka kõik selle alamdomeenid - ehk kui EIS teeb vea, siis on selle tulemusena kõik .ee lõpulised domeenid kättesaamatud. TLD tasemel on aastate jooksul olnud kümneid juhtumeid, kus kogu tippdomeeni nimeruum on “maas”. Domeeni omaniku vaatest võib tema teha kõik võimaliku ja isegi veidi võimatu, et DNSSEC toimiks ja oleks korras, aga kui vanem eksib, on ka hoolsa domeeni omaniku teenused kättesaamatud.

Ettepanek - hoida tagasi DNSSECi forseerimist seni, kuni on saavutatud palju palju kõrgem töökindlus. Meenutades aga ka deSECi esitlust, oleks DNSSECi automatiseerimine samm just  töökindluse parandamise suunas. Seega võiks seda edasi suruda isegi siis, kui tõmmata DNSSECi promo maha.

Ka DNSSECile tuginev DANE ei “lenda”, sest puudub sirvikute tugi. Internetilehitsejate arendajad ei soovi seda juurutada, sest neile on lihtsam ja kiirem kontrollida sertifikaate DNSi asemel vastu kohalikku sertifikaadihoidlat. Õnneks on projekte nagu Kanada registri CIRA e-identiteedi ülepiiriline kontrolli lahendus, mis toob fookusesse alternatiivseid DNSSECi ja DANE kasutusulugusid.

Väiksematest kõrvalepõigetest selgus, et Rootsi register on tagasi oma algse pilvenägemuse juures ning arendatakse hübriid-pilvelahendust - plaanivad panna oma registrisüsteemi paralleelselt tööle nii Amazoni kui Google pilvedes. Selline lahendus teeb suure sammu kaugemale kulutõhususest, kuid see polegi peamine - pigem on eesmärgiks töökindlus ja soov maandada sõltuvusriski konkreetsest teenusepakkujast. Kindlasti on tegemist projektiga, millel tasub silm peal hoida ja millest õppida arvestades meie endi pilve ambitsioone.

Seoses kogukonnale tagasi andmise mõtetega oli huvitav kõnelda inimestega Jaapani registrist, kes panustavad noorte koolitamisse, käies koolides rääkimas oma tööst ja DNSist. Miks ei võiks midagi sellist ka meie teha - tutvustades noortele DNSi, registreid, rääkida turvalisusest, õpetada DNSi “häkkima” ja tutvustada lahendusi nendele ründevektoritele jne.

Minuni jõudis ka päris mitmeid mõtteid ja ettepanekuid meie oma lahenduste tutvustamiseks ICANNis ja CENTRis - meie isikutuvastuse lahendused, oksjonid ja Restful tehnoloogial põhinev liides registripidajatele. Näib, et uuel aastal saab palju esineda.