DNSSEC-prosjekt referat fra arbeidsgruppemøte i Oslo 2013-02-28

UN2013--058 1 (13) DNSSEC-prosjekt referat fra arbeidsgruppemøte i Oslo 2013-02-28 Referat fra DNSSEC arbeidsmøte

UN2013--058 2 (13) Document History Date Revision Author Comment 13.03.2013 0p1 Trond Haugen Initiell versjon av referat fra arbeidsmøte. List of contents: 1 Introduksjon... 3 2 Diskusjonspunkter... 3 2.1 Avklare hvordan en kan gjøre det enkelt og forretningsmessig interessant for registrarene å tilby DNSSEC til sine kunder.... 3 2.2 Krav til kompetanse hos registrarer og mulige opplegg for å opparbeide denne... 4 2.3 Konkrete endringer i EPP-grensesnittet... 5 2.3.1 Hvilke DNSSEC utvidelser skal vi ta i bruk?...5 2.3.2 Hvordan skal registrarbytte (transferprosedyren) være?... 7 2.4 Rolleavklaringer for registrarer, DNS-tilbydere, registry og registranter, hvordan oppdatere nøkler i registry?... 7 2.5 Problemstillinger ved skifte av DNS operatør... 8 2.6 Hvilke hjelpe-verktøy og/eller -tjenester Norid bør tilby... 9 2.7 Hjelpe til med å få slått på validering hos resolveroperatører... 10 2.8 Utarbeide krav og/eller anbefalinger for DNSSEC-relatert programvare som passer for registrarer... 11 2.9 Opplegg for utrulling av og blæsting om DNSSEC for.no.... 12 2.10 Annen informasjon fra Norid... 13 2.10.1 DNSSEC Policy and Practice Statement (DPS)... 13 2.10.2 HSM (Hardware Storage Module) eller ikke?... 13 2.10.3 Sonefilproduksjonen... 13

UN2013--058 3 (13) 1 INTRODUKSJON Dato: 2013-02-28 Møtested: Felix konferansesenter I Oslo Til stede: Alle som var innmeldt til møte, se agenda for liste over deltakere. Tema: Se agenda for innhold og temapunkter for møtet. 2 DISKUSJONSPUNKTER Agendaen lister 9 punkter/temaer som ble gjennomgått. Punktene gjengis under, med de kommentarer som framkom under møtet. For noen punkter har Norid har lagt til noen tilleggskommentarer for å supplere informasjonen. 2.1 Avklare hvordan en kan gjøre det enkelt og forretningsmessig interessant for registrarene å tilby DNSSEC til sine kunder. 1) Registrarlistene Norid vil merke DNSSEC-kapable registrarer i registrarlistene som vi publiserer på weben. Dagens lister kan med forel slås sammen til en matrisepresentasjon, hvor man kan sortere feks. på kolonner. 2) DNSSEC-støtte bør bli påkrevd på sikt: En registrar må kunne håndtere DNSSEC, feks. innen innen 2 år etter prodstart. Det som da bør kreves er å kunne håndterere håndtere innlegging og fjerning av DS/DNSKEY i EPP som minimum. Et basiskrav om å måtte håndtere DNSSEC for å være registrar kan da inngå i registrarkontrakt 3) Viktig å unngå innlåsing av kunder, må kunne flytte en kunde like enkelt som i dag. 4) Gi incitamenter (økonomi/rabattordninger): Registrarer ønsker en rabattordning. Tilbakebetaling etterskuddsvis er greit. Hvert halvår er litt sjeldent, kvartalsvis eller hver måned er bedre. NL/SE krever forøvrig også at domenener validerer også før tilbakebetaling utføres. 5) Norid må gjøre det enkelt å ta i bruk DNSSEC, derfor må EPP-klienten støtte dette. 6) Norid bør synliggjøre at DNSSEC er i bruk eller ikke på et domene (whois). 7) DNS-sjekker kunne feks hinte om at DNSSEC anbefales dersom det mangler. 8) PTs nettsjekk eller nettfart-tjeneste kunne si noe om DNSSEC er tilgjengelig eller ikke hos ISPer/resolvere. Via mediakanaler kan tekniske sluttbrukere bli interessert. 9) La markedet ellers styre utviklingen. her er det jo også et konkurranseaspekt, ved at registrarene kan promotere seg med at: en registrar som tilbyr DNSSEC er mer seriøs og 'i front' enn n som ikke gjør det et sikret domene er tryggere enn et usikret, og dermed et bedre produkt DNSSEC muliggjør nye tjenester (DANA..)

UN2013--058 4 (13) 10) Andre viktige kommentarer: Hyppigere soneoppdateringer må komme (24/7/365) Norid er klar over dette, og utvikler for tiden en automatisert sonefil-pipeline, som skal brukes for DNSSEC-produksjon. En første versjon av denne skal kunne brukes i dagens system, og da kan vi endelig få i gang automatisert produksjon og publisering. Frekvens for publisering vil da være en ren konfigurasjonssak, men med en nedre praktisk grense for hyppighet, typisk ikke oftere enn hver. 2. time. Navnetjenersjekken må fjernes/justeres, med DNSSEC kan eierskifte bli enda vanskeligere. Heller sjekk DNS offline, og send (gjerne også mailbasert) varsel til registrarer om de som har problemer. Merk: at offline DNS-sjekking pågår i dagens system, og at statusdumper som lister domener med DNS-problemer ligger på registrarweb. Dersom man må oppdatere DS, og navnetjenersjekken feiler, så avvises DS oppdatering, derfor MÅ navnetjenersjekken også fjernes! Norid nevner også: at vi anser at det er greit at en registrar signerer alle sine delgeringer uten å innhente eksplisitt tillatelse fra hver abonnent, et slikt krav vil undergrave muligheten for å nå målene som Norid har om antall signerte domener. Om vi får med de 10 største registrarene vil vi kunne nå målet på 65% signerte domener. Norid vil snakke med PT og myndigheter for å se om de kan legge press på viktige aktører i samfunnet om å bruke DNSSEC. 2.2 Krav til kompetanse hos registrarer og mulige opplegg for å opparbeide denne Hva behøver en registrar å vite? Hvordan finner han ut det han trenger å vite? Kan dot-enno hjelpe til, og hvordan? Bør Norid hjelpe til, og hvordan? (Sponse kurs, holde kurs, annen måte?) 1) Norid bør kunne kreve DNSSEC-støtte på sikt fra alle registrarer, feks. innen to etter oppstart. 2) Det er lettere nå enn før å tilegne seg kunnskap. Det er registrarer som samtidig er DNS-operatører som vil ha største jobben, og de kan feks. starte med å signere et domene hos.se feks. og få erfaring. 3) Større registrarer finner ut av dette selv. 4) Opplæring av små registrarer er viktig dersom alle de også skal med. (Dersom de ikke drifter navnetjenere selv er vel ganske enkle.).se har kjørt kurs mot teknisk personale hos registrarer. 5) Lurt å opprette en DNS-operatør kanal (e-post-liste/forum for å kunne diskutere DNS og DNSSEC aspekter mellom hostingleverandører/isper.)

UN2013--058 5 (13) 2.3 Konkrete endringer i EPP-grensesnittet 2.3.1 Hvilke DNSSEC utvidelser skal vi ta i bruk? Norid tenker å bruke standard DNSSEC EPP utvidelser som definert i SecDNS-1.1 versjonen, se RFC5910, http://tools.ietf.org/html/rfc5910 Vi har allerede en tentativ kravspesifikasjon, men den har noen åpne punkter vi ønsker hjelp på. 1) Kap. 3.3 'Maximum Signature Lifetime' Norid foreslår: Dette er en valgfri parameter, og er en klientstyrt levetid på RRSIG signaturen over sine DS. Vi ser problemer med å kunne støtte denne gjennom en signerings-pipeline, og ønsker å avvise denne i EPP-snittet. (AT og flere andre forbyr denne i sine EPP-snitt, så vi tror det skal være greit å utelate støtte for denne). Denne parameteren ble ikke omtalt/diskutert på arbeidsmøtet. Er det noen som ser problemer med å avvise bruk av denne? 2) Kap. 4: DS Data Interface and Key Data Interface. Et av disse alternativene skal velges i EPP snittet. Det er tre mulige varianter. E1, E2 og E3 under illustrerer disse, alle er hentet fra http://tools.ietf.org/html/rfc5910#page-14: E1: Example use of the secdns-1.1 DS Data Interface for a create: <secdns:dsdata> <secdns:keytag>12345</secdns:keytag> <secdns:alg>3</secdns:alg> <secdns:digesttype>1</secdns:digesttype> <secdns:digest>49fd46e6c4b45c55d4ac</secdns:digest> </secdns:dsdata> E2: Example use of secdns-1.1 DS Data Interface with option key data for a create: <secdns:dsdata> <secdns:keytag>12345</secdns:keytag> <secdns:alg>3</secdns:alg> <secdns:digesttype>1</secdns:digesttype> <secdns:digest>49fd46e6c4b45c55d4ac</secdns:digest> <secdns:keydata> <secdns:flags>257</secdns:flags> <secdns:protocol>3</secdns:protocol> <secdns:alg>1</secdns:alg> <secdns:pubkey>aqpj////4q==</secdns:pubkey> </secdns:keydata> </secdns:dsdata> E3: Example use of the secdns-1.1 Key Data Interface for a create: <secdns:keydata> <secdns:flags>257</secdns:flags> <secdns:protocol>3</secdns:protocol> <secdns:alg>1</secdns:alg> <secdns:pubkey>aqpj////4q==</secdns:pubkey> </secdns:keydata>

UN2013--058 E1 og E2 er DS-varianter, mens E3 er en ren DNSKEY-variant. 6 (13) Norid foreslår: å gjøre som.nl og bruke E3-varianten fra kap. 4.2: 'Key Data Interface' (DNSKEY-varianten). Det innebærer altså at kap. 4.1: 'DS Data Interface' ikke støttes, og forsøk på innsending av DS data som I E1 eller E2 vil bli avvist I EPP-snittet. Effekter: Registry må generere DS selv. Varianten skulle gi et enklere liv for registrarene da de bare behøver å forholde seg til DNSKEY. Digestalgoritme kan bestemmes av registry, og evt. algoritme-rollover kan da også gjøres av registry uten å blande inn registraren. Domeneshop mener at DS bør brukes, ikke DNSKEY, da DS er mest utbredt. Ref. også 'Operational practices': http://tools.ietf.org/html/rfc6781#section-4.3.2, hvor det påpekes at DS gjør det mulig å bruke algoritmer som ikke støttes av registry. Larsen Data sier at DNSKEY er brukt av flere (NL etc) Norid spørsmål: Litt avhengig om vi velger DNSKEY eller DS så kan forskjellige policysjekker legges til i EPP-snittet. Bør vi policy-begrense tillatte algoritmer slik at f.eks. de nyeste og lite utbredte/kjente (som GOST og nyere) ikke kan benyttes, eller er dette unødvendig, dvs. vi lar registraren bestemme dette fritt selv, og han må selv ta ansvaret for følgene? Merk: Vi kan komme til å begrense algoritmer som registry ikke støtter og som vi er avhengige av å kunne støtte ifm. interne sjekker etc.

UN2013--058 7 (13) 2.3.2 Hvordan skal registrarbytte (transferprosedyren) være? Transferprosedyren, hvordan bør den utføres: a) Mellom to registrarer som støtter DNSSEC: Her er det bare å overføre DNSSEC data! b) Til ny registrar som ikke støtter DNSSEC: Flg. alternativer finnes: a) avvise transfer b) utføre transfer, men beholde (kopiere) DNSSEC data. Vi forventer da at ny registrar som minimum er i stand til å selv fjerne DNSSEC data etter transfer, feks. ved å bruke vår EPP-klient. c) Utføre transfer, men registry sletter DNSSEC data. Skal noen/abonnnent varsles her, hvem, hvordan? Vi kan la være å varsle, men heller forutsette at registrar informerer om konsekvenser mot abonnent før transfer, dvs. at delegeringen vil ende opp med å være usikret. Kopier svensk modell - behold DS-data ved transfer! Ikke rør DNSSEC data ved bytte av registrar Ikke test at DNSSEC validerer. Vurder mail/notify til registrar ved transfer, evt. velge kanal for varsling på regweb (EPP default). Det må være enkelt å bytte registrar - ingen låsing. 2.4 Rolleavklaringer for registrarer, DNS-tilbydere, registry og registranter, hvordan oppdatere nøkler i registry? Oppdatering av nøkler må kunne utføres mot registry hvordan? 1) Kun via registrar og EPP-kanal 2) Abonnent/DNS-operatør kan gjøre det direkte mot registry via en ny tjeneste? Kommentar: Klar konklusjon: 1) skal gjelde, alt skal gå via registraren, ingen spesialtjeneste skal lages!

UN2013--058 8 (13) 2.5 Problemstillinger ved skifte av DNS operatør Skifte av DNS operatør er ikke dekket av EPP-protokollen. Skifte behøver ikke, men kan innebære registrarskifte. Det finnes en draft som beskriver problemstillingen og foreslår en prosedyre og løsning: http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04 dokumentet supplerer kap. 4.3.5 i http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-13 Ved skifte av DNS operatør vil nye nøkler brukes av ny operatør, mens bare gammel operatør sine nøkler finnes i DNS. Ubrutt sikret delegering og validering er ønskelig, men da må nøkkelutveksling mellom operatørene finne sted. Men, å gå usikret er bedre enn å havne i situasjon med valideringsfeil. 1) Ny operatør kan finne nøkkel for gammel operatør i DNS, og leggedenne til i sin kopi av sonen. 2) Gammel operatør må få ny nøkkel fra ny operatør på en eller annen *sikker* måte, og så publisere ny nøkkel i tillegg til den gamle. en foreslår at registry kan tilby en sikker 'dropbox' for utveksling av ny nøkkel fra ny til gammel operatør. Hvordan forholder vi oss til problemstillingen? Skal registry legge til rette for en dropbox (DNSKEY relaying) funksjon, som omtalt i draften? Dette er interessant kun dersom/når det kommer en RFC, ikke prioriter dette. Prosedyren er ellers registrarenes og DNS operatørenes ansvar. Vanlig rutine vil være som i dag. Med DNSSEC blir det i tillegg å avsikre, bytte og sikre igjen, for 99.8% av alle kunder er dette helt uproblematisk. Evt. lage anbefalinger på hvordan et bytte skal gjøres. Må ha høyde for at tredjepart er hva som helst. Saken holdes på is, men vi følger med på utviklingen.

UN2013--058 9 (13) 2.6 Hvilke hjelpe-verktøy og/eller -tjenester Norid bør tilby 1) En del generell informasjon om DNSSEC vil komme på web, på norsk og engelsk. To vinklinger: En for mannen i gata En seksjon for registrarer eller tekniske krav. 2) EPP-tjenesten blir selvsagt oppdatert med DNSSEC iht. EPP-spesifikasjonen. 3) Vi kommer til å utvide vår EPP-klient med full DNSSEC støtte iht. EPP-spesifikasjonen, til hjelp for små registrarer. 4) Registrarprøven Denne vil bli utvidet med støtte for å teste DNSSEC-parametre også. 5) Registrarweb Ny parameter innføres som sier om en registrar er 'DNSSEC-kapabel' eller ikke. Kan brukes for å tillate bruk av DNSSEC-parametre i domain-create/update, samt styre hvordan transfer-prosedyren skal oppføre seg. Dersom DNSSEC-sertifisering skal utføres, ved at ny DNSSEC-del i registrarprøven skal være gjennomført, kan verdien skrus på kontrollert av Norid når sertifisering er utført og bestått. I dette tilfellet må parameteren kunne settes kun av Norid. Kommentar: La registrarene styre denne om det er praktisk mulig. 6) Vi kommer til å tilby en oppgradert dnschecker, med DNSSEC-støtte 7) Registrarweb-dumper. Vi tenker å ta med DNSSEC info. i regwebdumper, får se om DNSSEC data legges i ny dump eller utvide en av dagens dumper 8) Whois-tjenesten: DNSSEC info. må vises. To varianter av detaljer kan tenkes: Vise kun et flagg som sier signert (y/n)? Vise flere detaljer, også DS poster på samme måte som NS y/n burde holde. En bruker kan bli forvirret dersom key/ds-data vises. Ellers burde layout på whois-proxy gjøres mye mer brukervennlig. Til slutt kom det opp et spørsmål om Norid burde tilby en proxy-funksjon for sonefiloverføring mellom operatører? Stor motstand mot det, så den ble lagt død fort.

UN2013--058 10 (13) 2.7 Hjelpe til med å få slått på validering hos resolveroperatører ISPer og andre som driver resolverende navnetjenere må skru på validering i sin konfigurasjon. Kan registrarene hjelpe til å etablere kontakt med disse og få dette til? Registrarene bør kjøre noe som validerer selv (siden en del kjører navnetjenere selv). Finne hvilken windowsversjon som støtter DNSSEC og anbefale at validering skrus på TDC hadde ingen tro på at de kan kontakte noen og få ting slått på. Fra e-post til dnssec-lista fra Ståle: Det er fremdeles et problem at det finnes en del ødelagte resolvere der ute. For eksempel har bind 9.7.4 og 9.8.1 en alvorlig bug som gjør at de ikke klarer å validere wildcard-records signert med NSEC3 (fikset i 9.7.5, 9.8.2 og 9.9.x). Utrolig nok er det noen ISPer som fremdeles bruker disse gamle versjonene og som har skrudd på dnssec-validering! Jeg snakket senest i går med en stor svensk kunde av oss som hoster noen hundre tusen siter på et wildcard-domene, og de opplevde plutselig at mange av deres brukere ikke kom inn på sidene etter at vi skrudde på dnssec på sonen deres for noen dager siden. Vi har derfor vært nødt til å skru av dnssec igjen for denne kunden. Slike ting lover IKKE bra for utrulling av dnssec, og når en stor Linux-distributør som Debian fremdeles shippes med en ødelagt bind 9.7.3-resolver, så er det så man får lyst til å stange hodet hardt i skrivepulten... En liste over plattformer/versjoner/opsyser og status hadde vært nyttig. Kommuniser gjennom en NOC (liste) over nettverksoperatører at dette er viktig. Ikke bare et norsk problem - må kommunisere med hele verden. ISPer kan skru på validering i forkant, men da kan det smelle når vi skrur på for.no, så da må de informeres om at så skjer, og at de må følge med. Ha en tjeneste som viser valideringsstatus. Kan kjøre en kampanje - her kan du sjekke ditt domene. AltiBox, Get, NextGenTel, Canaldigital kan kontaktes her. Ellers kjører bare Norid sitt løp uavhenging av hva som skjer på valideringssiden, og validering vil komme på etterhvert, og kan bearbeides i ro og mak etterhvert.

UN2013--058 11 (13) 2.8 Utarbeide krav og/eller anbefalinger for DNSSEC-relatert programvare som passer for registrarer Programvare Rutiner/roller HSM (Hardware Storage Module) eller ikke Norid vil selv bruke OpenDNSSEC i starten, med SoftHSM. Migrasjon til HSM etterhvert kun dersom nødvendig. IInformasjon på Norids sider om gode SW-pakker og også best practices. Men verden sett fra Norid og en registrar/operatør kan være forskjellig, så Norid bør også kunne ta i mot tips om sw som finnes, og legge det til i oversikten. Altså: Slik vi har gjort for EPP-systemet/Draupne.

UN2013--058 12 (13) 2.9 Opplegg for utrulling av og blæsting om DNSSEC for.no. Norid snakker med PT og myndigheter og forsøker å få dem til å legge føringer. Hva behøves mot markedet ellers, kan registrarene bidra eller ha forslag? PT bør signere sitt egen domene. En statsråd bør innhentest til å si at dette er viktig - samt forestå en åpning. NORCERT/NSM kan brukes. Informasjon om at nå er det mulig å sikre sitt domene, og at de aktivt kan sjekke sitt domene på en gitt tjeneste. Den spesielle 'sjekk ditt domene' tjenesten kan blæste dvs. si at hey, ditt domene er ikke sikret, gå til dinregistrar og få slått på DNSSEC. Abonnenter må i tillegg kreve av sine ISPer at de validerer, da kommer presset derfra også.

UN2013--058 13 (13) 2.10 Annen informasjon fra Norid Ting vi hadde på lista på møtet, men som det ble lite snakk om. Til informasjon. 2.10.1 DNSSEC Policy and Practice Statement (DPS) Norid kommer til å lage et DPS (DNSSEC Policy and Practice Statement) iht. format og innhold som anbefalt av RFC6841 (http://tools.ietf.org/html/rfc6841). En DPS inneholder bla. beskrivelse av registryets nøkkelvalg, algoritmevalg, prosedyrer for rollover, og litt om infrastruktur og hvordan vi har sikret signeringskjede og nøkkelinformasjon. Vi vil baserere våre valg av algoritmer og andre verdier på best-practices fra se, nl og at. DPS-dokumentet skal publiseres på vår web sammen med annen teknisk informasjon. Vi lager en første versjon og sender til kommentering hos arbeidsgruppa. 2.10.2 HSM (Hardware Storage Module) eller ikke? En HSM kan brukes for generering og sikker lagring av nøkler, samt signering. Norid vil forsøke å bruke SoftHSM i starten, og evt. migrere til HSM dersom behovet dukker opp, eller noen evt. 'krever' det. Registrarene (eller egentlig DNS operatørene) må selv finne ut hva de behøver. Tips: SoftHSM følger med OpenDNSSEC pakken, men kan brukes som en separat HSM-modul også. 2.10.3 Sonefilproduksjonen Som nevnt under punkt 2.1, så jobber Norid med en ny, og automatiserbar pipeline for produksjon av sonefiler. Settes først i drift for usignerte soner. Signeringsmodul kan så plugges inn. For signeringen av no-sonen ser vi for oss å bruke NSEC3 med opt-out i starten, det virker å være en anbefalt og mye brukt variant i startfasen, og er hensiktsmessig så lenge et mindretall delegeringer er signert.