In de consultatieronde zijn ten aanzien van het expertadvies over de standaard DNSSEC reacties ontvangen van de volgende organisaties:

Bureau Forum Standaardisatie Bezoekadres: Wilhelmina v Pruisenweg 52 2595 AN Den Haag www.logius.nl Datum 30 augustus 2012

In de consultatieronde zijn ten aanzien van het expertadvies over de standaard DNSSEC reacties ontvangen van de volgende organisaties: Belastingdienst (p.1) BKWI (p.3) EL&I (p.13) KvK (p.14) Stichting NLnet (p.15) Proxy Laboraties B.V. (p.18) UWV (p.19)

N.B. Waar in de tekst: (…) wordt weergeven, zijn de commentaren m.b.t. andere standaarden weggelaten.

Belastingsdienst ________________________________ From: Berlo, GJA (Ger) van (IVB/DH) Sent: Monday, March 12, 2012 10:14:53 AM (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna To: Openstandaarden Cc: Borgers, Michiel - IVB/DH (Min. van FIN); Sijstermans, Wim MT (Min. van FIN) Subject: Betr: FW: Openbare consultatie, DKIM, DNSSEC, ODF, PDFA2, SIKB, VISI en WSRP standaarden L.S., Bij deze stuur ik u het standpunt van de Belastingdienst inzake de openbare consultatie van de standaarden DKIM, DNSSEC, ODF 1.2, PDF/A-2 en WSRP. De twee andere standaarden, te weten SIKB en VISI, zijn voor de Belastingdienst niet relevant

Pagina 1 van 19

(…) Opname DNSSEC

Bureau Forum Standaardisatie Datum 30 augustus 2012

DNSSEC is één van de bouwstenen op weg naar een veiliger gebruik van het internet. Invoering van deze standaard betekent een stukje meer complexiteit en nauwgezetheid van beheer, maar deze 'nadelen' vallen in het niet bij de grote voordelen die deze standaard biedt bij internetverkeer tussen overheid en burgers/bedrijven. Opgemerkt wordt dat er wel een zekere afhankelijkheid lijkt te bestaan m.b.t. keuze van browsers. Microsoft ondersteunt DNSSEC in haar productsuite namelijk maar ten dele. De IE browser ondersteunt DNSSEC nog niet. Als dat zo blijft in de toekomst, dan ligt daar wel een aandachtspunt! Nu is het altijd zo geweest: je hebt Microsoft browser en de rest, waarbij IE van Microsoft meestal zorgt voor de meeste complexiteit en problemen. De overige veel gebruikte browsers ondersteunen DNSSEC al wel standaard of via een plug-in. Standpunt van de Belastingdienst: we staan zonder enig voorbehoud achter het advies van de expertgroep aan het standaardisatieforum. (…) Mocht u hierover nog vragen hebben dan kunt u met mij contact opnemen. Vriendelijke groet, Ger van Berlo Senior beleidsmedewerker ................................................................. ............. Ministerie van Financiën Directoraat-Generaal Belastingdienst Cluster IV

Pagina 2 van 19


BKWI

Publieke Consultatie DNSSEC

Inhoudsopgave 1. Inleiding

4

2. Onze bevindingen t.a.v. het expert-adviesdocument

4

3. Aanvullende Adviezen aan het Forum

Auteur:

ir. Willem Kossen, ICT-Architect

Datum document:

11/3/2012

Versie:

1

Status:

(Concept)

12

Datum afdruk:

Pagina 3 van 19

Inleiding


Met interesse hebben we kennisgenomen van het expertadvies omtrent de standaard DNSSEC aan Forum Standaardisatie. We hebben daar de nodige opmerkingen bij die we middels dit stuk in de fase van publieke consultatie kenbaar maken. ‘We’ betekent in dat kader Willem Kossen (ICT-Architect) en Bart Smit (Netwerkspecialist) van BKWI. We zullen in dit document reageren op het document zelf, maar daarnaast ook wat eigen inbreng weergeven die waardevol zal zijn in het verdere besluitvormingstraject. We zullen daarbij niet trachten al onze opmerkingen precies in de structuur van uw consultatiedocument te gieten. Ons inziens vergemakkelijkt dit het verwerken aangezien enerzijds helder wordt op welk deel van het expertadvies de reactie van toepassing is, en anderszijds onze eigen reactie als samenhangend stuk tekst kan worden gelezen. Het zal u opvallen dat ons document wat ‘lijsterig’ van karakter is door het aantal punten waarop we willen reageren. In essentie zijn wij niet tegen DNSSEC en zien we dat dit in de toekomst zeer waardevol kan zijn om meer vertrouwen te verkrijgen in het bezoek van de juiste systemen (web, mail, enz) Het advies is wat ons betreft op een aantal punten onjuist, onvolledig en ongenuanceerd. Daarnaast hebben wij niet oneindig veel vertrouwen in het effect van de PTOLU lijst, er is zeker veel meer nodig, maar dat is uiteraard geen onderdeel van het expert-onderzoek, wat ons niet weerhoudt deze zaken wel aan te stippen. In z’n algemeenheid zien we DNSSEC wel graag op de lijst, maar met een breder toepassingsgebied en meer correcte en genuanceerde argumentatie. Hierna volgend een aardige samenvatting die we haalden uit een van onze bronnen: DNSSEC may help, if done right Otherwise it will hurt! ( http://ds9a.nl/har-presentation-bert-hubert-3.pdf )

Onze bevindingen t.a.v. het expert-advies

Pagina 4 van 19

Algemene bevindingen

Bureau Forum Standaardisatie

We missen in het document een goede duiding van de DNS systematiek. Van de rollen die verschillende technische actoren daarin kunnen hebben zou bijvoorbeeld een verhelderende afbeelding kunnen worden opgenomen. Dan kan ook telkens in

Datum 30 augustus 2012

de tekst de juiste benaming worden gebruikt. Een resolver is een DNS server, een authoritatieve server en een cache ook, maar hun rol is heel anders. Het begrip server of systeem is daardoor sterk multi-interpretabel. Het maakt nogal uit over welk deel van het DNS landschap we het hebben. Dit verdient verbetering in het document. Mogelijk is een dergelijke plaat als de hiernavolgende een goede toevoeging:

Bron hiervan is http://ds9a.nl/har-presentation-bert-hubert-3.pdf

Door het opnemen van zo’n overzicht kan ook eenvoudig worden aangegeven voor welke rollen we DNSSEC ondersteuning PTOLU willen verplichten in de productselectie en aanschaf, en in welke systemen we ook de implementatie PTOLU willen verplichten (iets waarvoor de huidige lijst geen instrument bevat). De ervaring leert dat slechts weinigen de verschillende functies en rollen voldoende uit elkaar houden om de misverstanden te beperken. Dat is in het expert-adviesdocument ook niet gelukt. Ik beloof als auteur van deze reactie evenmin dat mij dat volledig zal lukken (mede door de tijdsdruk waaronder ook dit document is ontstaan). Het is echter voor een advies waarop belangrijke besluitvorming gaat berusten van groot belang dat de terminologie en begripsvorming deugt. Het verzoek is dan ook het hele document op dit punt na te lopen en waar nodig te verbeteren.

Pagina 5 van 19

Bevindingen bij hoofdstuk 1


Ons eerste punt betreft de samenstelling van de expertgroep zoals vermeld in paragraaf 1.4. Ons inziens ontbreekt een sterke vertegenwoordiging van overheidsorganisaties die de standaard zouden moeten gaan toepassen. Immers de impact op


hun is voor het advies van groot belang. Om die reden zouden we julst een vertegenwoordiging verwachten van de (ICT-verantwoordelijken) vanuit diverse sectoren van de overheid, uit verschillende bestuurslagen en de uitvoering. Nu is alleen de sector onderwijs vertegenwoordigd. Dit kan (zeker gezien het feit dat daar voorop wordt gelopen) een vertekend beeld geven. Bevindingen bij hoofdstuk 2 Er ontstaat gelijk een probleem bij het toepassingsgebied. Hier is namelijk niet duidelijk om wat voor systemen en diensten het gaat. Zoals eerder gesteld zijn er verschillende rollen die systemen in het DNS landschap vervullen. De suggestie die van de tekst uitgaat is dat het gaat om authoritatieve servers gaat. Daarbij wordt de beperking gemaakt dat het vooral om internetgebaseerde DNS servers gaat en niet om ‘interne servers op LAN netwerken’. Je moet je afvragen of je die uitsluiting moet willen, aangezien je misschien Juist wilt voorkomen dat je met een interne gehackte DNS server overheidsprofessionals naar ‘fake-sites’ stuurt voor het verkrijgen van bijvoorbeeld inloggegevens van bedrijfsapplicaties. Dit is niet denkbeeldig. Bovendien geldt de PTOLU constructie voor het aankopen/aanbesteden van domeinserversoftware en diensten, maar niet op het ook daadwerkelijk implementeren ervan. En dat onderscheid wordt niet nadrukkelijk genoemd. Voor DNSSEC op internetdomeinnamen zou je wat ons betreft ook de implementatie onder bepaalde voorwaarden willen ‘verplichten’. Ons inziens is dat echter nog steeds onvoldoende. Het signeren van domeinen alleen is niet voldoende voor het bereiken van de doelen van veiligheid. Zonder het PTOLU verplichten van het selecteren en aanschaffen van clientsoftware en resolvers die in staat zijn (maar niet per se ook zo geconfigureerd zijn) DNSSEC validatie te doen bereiken we nooit op een redelijke termijn (5 jaar) een situatie waarin DNS binnen de overheid en daarbuiten op een veiliger niveau kan worden gebruikt. Die uitsluiting is ons inziens dus ongewenst, ook al realiseren we ons dat er de komende paar jaar nog redelijke ‘leg-uit’ gronden zijn aan de validatiekant. Het probleem is dan ook dat wanneer we dit nu niet langzamerhand de goede kant op duwen (met PTOLU) we ook niet makkelijk in de toekomst de gewenste uitkomst hebben. Bovendien, wanneer gaan we die aanpassing dan wel doen? Moeten we dit ‘jaarlijks evalueren’? Daartoe heeft het Forum ook niet de procedures geregeld. Ook is de doelgroep onduidelijk. Je zou DNSSEC gesignde overheidsdomeinen moeten aanbieden aan de ‘buitenwereld’ om vertrouwen te ondersteunen bij de overheid, maar je wilt ook vertrouwen hebben in sites van anderen. Bijna alle overPagina 6 van 19

heidsorganisaties nemen wel ergens een SAAS (Software As A Service) pakket af,


al is het maar voor de boekhouding. Het kunnen vaststellen dat je van de juiste DNS systemen de juiste IP-adressen krijgt en dus op de juiste webserver uitkomt waar je je wachtwoord intypt is dan ook van levensbelang.


We zullen een keer moeten beginnen met het mogelijk maken van de validatie, wat ons betreft let iedereen daar nu al op bij de aanschaf en het ontwikkelen van software. t.a.v. de eerste bullet op pagina 11 zijn wij het roerend met het uitgangspunt eens dat zonder automatische verwerking geen PTOLU mag gelden. De risico’s zijn anders te groot. T.a.v. de laatste bullet van paragraaf 2.1 (pagina 11) zijn wij het niet eens met de expertgroep. Validatie op een tussenliggend netwerkcomponent is niet juist. Dit komt omdat de gebruiker dan niet de informatie krijgt over het probleem dat is opgetreden. Een ‘site-niet-gevonden’ melding leidt tot veel onduidelijkheid en frustratie, en bovendien extra belasting van helpdesken en beheerders, die ook niet zo makkelijk zullen achterhalen wat er werkelijk aan de hand is. De beste plaats voor validatie is in de client van de gebruiker. Het gebrek aan DNSSEC ondersteuning in browsers is een tijdelijke zaak (naar wij vermoeden) en vooralsnog een voldoende leg-uit grond. Het zou als aanvullend advies vanuit het forum waardevol zijn organisaties te adviseren in hun browserkeuze hiermee rekening te houden. We moeten echter niet onderschatten wat er verder aan ‘clients’ bestaat. De interne resolvers in besturingssystemen en netwerkcomponenten, resolvers in maatwerkapplicaties en resolvers in aangekochte applicaties. Er zijn vele implementaties in omloop en het zal veel tijd vergen tot een volledige dekking te komen. Juist daarom is een PTOLU bij aanbesteding/aanschaf/ontwikkeling ons inziens zo belangrijk. En dat staat dan weer los van de keuze de validatie ook ‘aan te zetten’ reeds op dit moment . Terzijde ook de opmerking dat browsers niet de enige clients zijn met een eigen stubs en resolvers. Denk aan smartphones, netwerkdoosjes, tablet computers, allerlei apps, maar ook veel ‘serversoftware’ die eigen dns-libraries aan boord hebben (java, .net, enz). Opmerkingen bij hoofdstuk 3 Paragraaf 3.2 start begint problematisch. Er is bij deze standaard namelijk helemaal geen interoperabiliteitswinst. Dat is ook niet waar deze standaard voor bestaat. Wel zijn er andere voordelen. Deze worden echter niet helder samengevat, dus doen we hier een poging:

Pagina 7 van 19

DNSSEC kan de gebruiker onder bepaalde voorwaarden meer zekerheid geven


over de juistheid van het IP-adres dat wordt verkregen. Hierdoor is er minder kans dat de gebruiker wordt omgeleid naar een verkeerde server. Voorwaarden zijn bijvoorbeeld dat


DNSSEC in de gehele keten van DNSclient, via tussenliggende resolvers tot aan de autoritatieve server correct is geïmplementeerd. Samengevat: End to End Het is geen oplossing voor domeinen met afwijkende, maar identiek weergegeven karakters (unicode). Tevens geldt dat de voorwaarde is dat de instelling van de te gebruiken DNS-servers correct is (DNS-changer virus) Of de voordelen ook opwegen tegen de nadelen valt te bezien, maar daarop komen we terug t.a.v. End to End nog het volgende, dit betekent eenvoudigweg dat er dus geen quick-wins zijn. Eigenlijk levert het hele verhaal maar beperkt wat op als niet ‘iedereen mee doet’. Het gaat dus om een situatie van lange adem en het stimuleren van brede adoptie, niet alleen binnen de overheid, maar ook ver daarbuiten. Of een plaatsje op een lijst daar nou zoveel bij helpt valt te bezien, maar alle beetjes helpen… Paragraaf 3.2.1 geeft de omschrijving dat DNS aan de basis ligt van het internet. Dat lijkt toch niet helemaal juist. Wel juist is dat DNSSEC gaat om het verhogen van vertrouwen en dat het nadrukkelijk niet alle problemen oplost. In paragraaf 3.2.2 komen we gelijk in het antwoord het End to End probleem tegen. Een gat in de keten van DNS maakt dat de toegevoegde waarde enorm vermindert. Dit is inmiddels eerder nadrukkelijk toegelicht. De Firewall problematiek is bekend. Wat niet bekend is, is de omvang van het probleem. Let wel, we zouden DNSSEC nadrukkelijk implementeren als overheid om naar buiten toe vertrouwen te wekken. Het resultaat kan zijn dat we van buiten af niet meer bereikbaar zijn. Het is maar zeer de vraag of dat de bedoeling is. Dat er ‘voldoende publieke documentatie’ is over zo’n probleem betekent helemaal niet dat de mensen die hiermee worden geconfronteerd in staat zijn hun systemen aan te passen, door kennis of de beperking van systemen die simpelweg nog niet zijn afgeschreven. Paragraaf 3.2.3, pagina 17 Kosten. Wij hebben geen kosten inschatting kunnen vinden voor het beheer van DNSSEC domeinen. Het is echter zeer aannemelijk dat deze kosten sterk hoger zijn en wel op een aantal punten. Er zijn specifieke kosten Pagina 8 van 19

Het instellen van de signing en het maken van keys


Het onderhoud aan de keys moet worden ingericht (frequent vervangen, liefst geautomatiseerd) Hersignen bij iedere wijziging in de zone, wijzigingen zijn dus iets arbeidsin-


tensiever Er zijn algemene kosten Er wordt aanzienlijk meer servercapaciteit gebruikt (dus minder afhandeling per server) Er is meer dataverkeer Er zijn kosten die samenhangen met het optreden van risico’s Herstelacties bij foutief signen Langdurige downtime als gevolg van problemen met de signing en alle ‘collateral damage’ Ddos als gevolg van DNS-amplificatie Deze kosten zullen ‘bij de prijs inzitten’ wanneer je een service-provider contracteert, of vertalen zich in arbeidsloon wanneer je dit zelf doet. Het is op dit moment helemaal niet helder welke providers dit wel/niet en goed/slecht doen. Sterker nog, we vinden het helemaal geen goed idee als iedere overheidsorganisatie dit zelf moet gaan regelen. Op deze plek pleiten wij dan ook voor een overheidsbreed DNS-servicecentre waar vanuit de hele overheid en semipublieke sector de DNS dienstverlening kan worden afgenomen (en vanuit daar evt uitbesteed). Zo’n service centre kan hoogwaardige expertise opbouwen voor het correct uitvoeren van alle zaken die met DNS en DNSSEC samenhangen (en tevens voor gerelateerde zaken zoals DKIM en DANE in de toekomst) en kan dat tegen acceptabele kosten. Daarmee worden de andere overheidsorganisaties sterk ontzorgd. Mogelijk zou Logius zo’n rol kunnen vervullen, en wij kunnen ons voorstellen dat de indiener, SIDN, ook wel interesse zou kunnen hebben. We kunnen het niet laten door hier de term ‘RijksDNS’ maar eens te droppen… Om terug te keren naar de paragraaf 3.2.3 het volgende. Er wordt gesteld dat de baten opwegen tegen de kosten. Echter, de als gering ingeschatte kosten (zoals hierboven nader gespecificeerd) zijn niet de enige zaken die tegenover de baten staan. De risico’s en ‘gevolgschade’ daarvan dient men in de overweging ook nadrukkelijk mee te nemen. Het is dan nog maar de vraag of de balans op dezelfde manier uitkomt. Sterker nog, door het niet End to End implementeren van DNSSEC zijn de baten nog sterk beperkt ook. Het verhaal wordt dan een stuk minder vanzelfsprekend. Men gaat in het expertgroepadvies ook in op de ‘operationele risico’s die ‘in het begin van een nieuwe technische implementatie’ tot ‘technische/configuratie’ problemen kunnen leiden. Het is goed hier op te merken dat hele grote partijen al flinke Pagina 9 van 19

onbeschikbaarheid van hun zones hebben meegemaakt als gevolg van deze ‘pro-


bleempjes’. Partijen als NASA bijvoorbeeld. Omdat slechts weinigen daadwerkelijk DNSSEC-validatie toepassen valt dat probleem mee, maar dat zal, zeker nu grote browsers DNSSEC beginnen te ondersteunen (Chrome, Firefox) helemaal niet zo


blijven. Wij schatten dit probleem groter in. Dat wil niet zeggen dat je niet toch voor DNSSEC moet kiezen, maar dat je wel in je afweging serieus rekening met problemen moet houden en zult moeten accepteren dat je een risico loopt. Pagina 18 begint met een vreemd punt, DNSSEC zou juist een Denial of Service kunnen voorkomen. Wij hebben geen idee hoe, en navraag in ons netwerk geeft op dat punt ook geen uitsluitsel. Zonder nadere onderbouwing is dat punt wat ons betreft dus foutief. Paragraaf 3.2.4, de conclusie, bevat kort door de bocht een aantal stellingen waarop wij eerder nuanceringen hebben aangebracht. Die nuanceringen mogen natuurlijk in de conclusie terug komen. Paragraaf 3.2.4 bevat eveneens een punt van onjuistheid, waarschijnlijk als gevolg van ongelukkige formulering. Betere betrouwbaarheid van overheidswebsites wordt namelijk helemaal niet bereikt met DNSSEC. Alleen is het mogelijk (niet vanzelfsprekend) meer vertrouwen te wekken in het verkregen IP-adres. Over de website zelf wordt helemaal niets beloofd door DNSSEC. Ook neemt de kans op het bestaan van kwaadwillende websites niet af, wel de kans dat ze door mensen worden bezocht, op voorwaarde dat validatie wordt gebruikt en men de configuratie van DNS resolvers correct houdt (denk ook weer aan DNS Changer) Wat DNSSEC kan doen is – op voorwaarde van end-to-end – het vertrouwen vergroten dat men op de bedoelde server is uitgekomen, en daardoor verlagen we het aantal aanvalsvectoren dat kwaadwillenden kunnen toepassen. Het is van belang de nuanceringen nadrukkelijk ook in de conclusie weer te geven. Let wel, DNSSEC is dus een schakeltje in een veiliger internet, maar enkel een schakeltje. Het past binnen een breder palet van maatregelen die de veiligheid van het internet bevorderen. Daarbij horen oplossingen voor de problemen met PKI, email enz. Daarbij hoort vooral ook het inzetten van veilige software, waarin de DNS resolvers en stubs wederom een rol kunnen spelen. Het probleem met de procedure waarin we zitten is dat deze zo los lijkt te staan van al die andere dingen die ook moeten gebeuren. Er mist een samenhangend informatiebeveiligingsmissie bij de overheid. Wellicht kan daar ook vanuti Forum en College meer aandacht voor worden gevraagd. Het is ook niet helemaal juist dat er geen alternatieven zijn, afhankelijk van hoe je het toepassingsgebied en/of de doelstelling formuleert. Er zijn namelijk andere dinPagina 10 van 19

gen die je kunt doen om beetjes veiligheid aan DNS toe te voegen, zoals de sour-


ceport-randomization uit http://www.rfc-editor.org/rfc/rfc5452.txt, wat overigens geen standaard is maar een Best Current Practice. Uiteraard gaat dit veel minder ver dan DNSSEC.


Paragraaf 3.3 begint met een zeer belangrijke stelling. Ons inziens zit daar een flink deel van de crux van de discussie. Er zijn op dit moment wellicht 10 mensen in Nederland die werkelijk diepgaand snappen hoe DNSSEC werkt. Er zijn beslist nog weinig providers die dit echt goed kunnen toepassen, en er is al helemaal geen goede methode om de kwaliteit van die providers te vergelijken. De producten zijn er wel, maar de goed ingerichte processen en organisaties nog maar zeer beperkt. Dat is nadrukkelijk ook een onderdeel van marktondersteuning en tegelijk een groot risico. Zie ons eerder pleiten voor een centrale DNS-Support organisatie binnen de Overheid. Paragraaf 3.4, Opname bevordert adoptie. Wij verwachten dat er zeker in het begin weinig PasToe en veel LegUit zal zijn, waarbij vooral zal blijken dat bijna niemand het echt kan uitleggen. Wij pleiten voor PTOLU aan zowel publicatie als validatie kant en tevens voor het end2end inzetten van deze technologie. Daarbij zal PTOLU zelf weinig helpen als overheidsorganisaties niet nadrukkelijk ondersteund worden middels handreikingen, technisch advies, support en het daadwerkelijk aanbieden van de ontzorgende dienstverlening. (RijksDNS). Belangrijk blijft te bezien dat voor veel overheidsorganisaties zo’n handreiking nog steeds veel te complex zal zijn. Ontzorgen is hier echt het kernwoord. Paragraag 3.4.4 bevat een uitgangspunt waar wij bezwaar tegen hebben, namelijk dat DNSSEC functioneert uit het zicht van de gebruiker. Dat is nu juist wat je niet moet willen. Je wilt de gebruiker inzicht geven in wat er gebeurt. Natuurlijk is de hele serverkant en de technische uitwisseling buiten zijn gezichtsveld, maar laat de gebruiker niet in het ongewisse wanneer een validatie heeft gefaald. Door juist die validatie mede te stimuleren los je ook het kip-ei probleem op dat wordt genoemd. Een beetje als ‘Eat your own dogfood’. Signeren? Dan ook zelf valideren. Paragraaf 3.4.5, wij vinden de PTOLU plus een handreiking dus veel te mager. Er is echt meer nodig. De vraag daarbij is of het Forum ge-equipeert is om meer te doen. Daar ligt ook een taak voor SIDN en de eventueel toekomstige RijksDNS partij. DNSSEC alleen op de lijst plaatsen met een leuk pdfje erbij leidt niet tot een veiliger overheidsinternetgebeuren, maar tot veel frustratie en een heleboel leg-uit.

Pagina 11 van 19

Aanvullende Adviezen aan het Forum


Probeer als Nederlandse Overheid een convenant met de internet-serviceproviders van Nederland te bereiken op het implementeren van DNSSEC in alle facetten van hun dienstverlening zodat oude apparatuur wordt vervangen, burgers en bedrijven en overheidsorganisaties worden beschermd en domein-eigenaren beter worden ondersteund. Stimuleer het opzetten van een overheidsbreed intern DNS-service centrum dat alle overheidspartijen en partijen in de semi-publieke sector kan ontzorgen bij hun DNS perikelen. Verzamel daar de kennis en kunde en zorg voor hoge kwaliteit dienstverening op het gebied van DNS en DNSSEC (RijksDNS) Geef handreikingen over hoe organisaties in hun aanbesteding van software, netwerk-hardware, besturingsystemen en maatwerk ontwikkeltrajecten DNSSEC een plaats kunnen geven en op de juiste manier vereisen en implementeren Verlang met PTOLU niet alleen dat overheden ‘de mogelijkheid tot’ eisen, maar ook de DNSSEC daadwerkelijk implementeren, end-to-end aan zowel server als client kant. Stimuleer activiteiten die kunnen leiden tot een meer samenhangend informatiebeveiligingsbeeld in overheidsland. DNSSEC is maar een bouwsteentje in het veiligheidsgebeuren. Er moet een bewustzijn ontstaan, een richtlijn, een overzichtsbeeld, een stappenplan, enz. De informatiebeveiligingskatern van NORA zou bijvoorbeeld een onderdeel kunnen zijn. Organisaties als Govcert en Logius kunnen ook hier hun rol pakken. Wellicht kan SIDN op het gebied van Internet ook een bijdrage leveren.

Pagina 12 van 19

EL&I


________________________________ From: Rood, drs. P.H. (Pieter) Sent: Thursday, February 23, 2012 10:36:07 AM (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna To: Openstandaarden Cc: Romein, ing. H.J. (Henk); Middeljans, F.K. (Karin) Subject: FW: Openbare consultatie, DKIM, DNSSEC, ODF, PDFA2, SIKB, VISI en WSRP standaarden


Beste Maarten, Bij deze de reactie vanuit EL&I: We hebben geen commentaar bij de standaards ODF, PDFA2, SIKB en VISI. Bert Dingemans is vanuit EL&I bij WSRP betrokken. Voor DKIM zijn onze voorwaarden overgenomen , dus akkoord .

voor standaardstelling

DNSSEC De standaardstelling geldt alleen voor servers die met het publieke internet verbonden zijn. Er wordt gewaarschuwd voor de zwaardere beheereisen. Wij zijn voorstander van implementatie bij EL&I en ook van opname op de standaardenlijst. Aandachtspunt: In hoeverre de standaard ondersteund wordt door gangbare software is niet duidelijk, ook niet welke kosten gemaakt moeten worden ('DNSSEC validatie is zonder noemenswaardige kosten in te voeren ' en 'DNSSEC signing brengt ontegenzeggelijk kosten met zeg mee, en zal - zeker in het begin leiden tot hogere operationele kosten'). Wij zouden dit graag nog beter uitgezocht zien. Met vriendelijke groet, Pieter Rood ________________________________

Pagina 13 van 19

KvK

Memo


aan

van

Forum Standaardisatie

Rob Spoelstra

kenmerk

datum


13 maart 2012 onderwerp

Openbare consultatie DNSSEC Hierbij onze reactie op het Consultatiedocument DNSSEC van 13 februari 2012. 1. Zijn er volgens u in deze toelichting aanvullingen of anderszins wijzigingen nodig in de paragrafen 1.4. t/m 1.6 van het expertadvies (‘samenstelling expertgroep’, ‘toelichting standaard’ en ‘relatie met andere standaarden’), bezien vanuit het doel van het document (het Forum en College Standaardisatie voorzien van een inhoudelijk relevante toelichting). Nee. 2. Bent u het eens met het door de expertgroep geadviseerde functionele toepassingsgebied? Ja. 3. Bent u het eens met het door de expertgroep geadviseerde organisatorische werkingsgebied? Ja. 4. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het open standaardisatieproces? Ja. 5. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de toegevoegde waarde? Ja. 6. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het draagvlak? Ja. 7. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de bevordering van de adoptie door opname op de lijst? Ja. 8. Bent u het eens met de samenvatting van de overwegingen van de expertgroep? Ja. 9. Bent u het eens met het advies van de expertgroep aan het Forum m.b.t. opname van de standaarden op de lijst? Ja.

Pagina 14 van 19

10. Bent u het eens met de adoptie-aanbevelingen van de expertgroep aan het Forum Standaardisatie? Ja. 11. Is/zijn er volgens u nog andere informatie of overwegingen die aan het Forum en College Standaardisatie zou moeten worden meegegeven voor een besluit over het opnemen van deze standaard op de lijst met standaarden? Nee.


Groeten, Rob Spoelstra

NLnet

________________________________________ From: Michiel Leenaars Sent: Sunday, March 11, 2012 11:50:57 PM (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna To: Openstandaarden Subject: Reactie consultatie DNSSEC -----BEGIN PGP SIGNED MESSAGE----Hash: SHA1 Geacht Forum, bijgaand de reactie namens stichting NLnet met betrekking tot de consultatie rondom DNSSEC. Het is een goede zaak dat DNSSEC op deze lijst komt. Hier de antwoorden op de vragen: 1. Zijn er volgens u in deze toelichting aanvullingen of anderszins wijzigingen nodig in de paragrafen 1.4. t/m 1.6 van het expertadvies (?samenstelling expertgroep?, ?toelichting standaard? en ?relatie met andere standaarden?), bezien vanuit het doel van het document (het Forum en College Standaardisatie voorzien van een inhoudelijk relevante toelichting). Nee. 2. Bent u het eens met het door de expertgroep geadviseerde functionele Pagina 15 van 19

toepassingsgebied? [paragraaf 2.1 van het expertadvies] Het is een moeilijk houdbaar argument dat op dit moment niet alle software van alle leveranciers op de werkplek veilig is, en dat het daarom acceptabel is om de lokale werkplek (vallen hieronder ook smartphones?) buiten het werkingsgebied valt. Mogelijkerwijs is dat juist de belangrijkste plaats. Er is zoals wordt gesteld wel degelijk nu al de nodige software beschikbaar voor de clientzijde, ook voor zeer kwetsbare toepassingen zoals browsers.


Verplichtstelling zal leveranciers een sterke impuls geven om hun software aan te passen. De afweging of de beveiligingsrisico's om op de werkplek geen validatie van DNSSEC te maken moet door de gebruiker bewust gemaakt worden. 'Comply or explain' lijkt hier dus een prima regime - als het niet kan, is dat een prima uitleg. 3. Bent u het eens met het door de expertgroep geadviseerde organisatorische werkingsgebied? [paragraaf 2.2 van het expertadvies] Ja. 4. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het open standaardisatieproces? [paragraaf 3.1 van het expertadvies] Ja. 5. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de toegevoegde waarde? [paragraaf 3.2 van het expertadvies] Ja. 6. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het draagvlak? [paragraaf 3.3 van het expertadvies] Ja. 7. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de bevordering van de adoptie door opname op de lijst? [paragraaf 3.4 van het expertadvies] Ja. 8. Bent u het eens met de samenvatting van de overwegingen van de Pagina 16 van 19

expertgroep? [paragraaf 4.1 van het expertadvies] Het is niet juist om te stellen "De kans op door kwaadwillenden vervalste overheidswebsites neemt door het gebruik van DNSSEC af."


DNSSEC zal een vervalste site (e.g. rijkoverheid.nl) probleemloos valideren. Het internet kent bovendien vele toepassingen naast het web, die eveneens kwetsbaar zijn. Naast overheidseigen toepassingen (zoals mobiele apps) zijn ook generieke communicatie-toepassingen (zoals Voice over IP) beter beschermd wanneer DNSSEC verplicht is. Het is daarom juister om te stellen: "De kans op het door kwaadwillenden onderscheppen van internetverkeer binnen, tussen en met overheden neemt door het gebruik van DNSSEC af." 9. Bent u het eens met het advies van de expertgroep aan het Forum m.b.t. opname van de standaarden op de lijst? [paragraaf 4.2 van het expertadvies] Hier geldt de eerder gemaakte opmerking dat de risico's juist aan de gebruikerszijde aanzienlijk zijn - een laptop van een ambtenaar die vanaf zijn hotelkamer verbinding legt naar een intern systeem, zou anders mogelijk nog steeds buiten de werking vallen. Het is een gegeven dat systemen door gebruikers gebruikt worden op manier die niet voorzien zijn. Daarom zou toch kunnen worden overwogen om DNSSEC validatie te verplicht voor alle systemen die DNS gebruiken - ook al zijn die niet direct aan het publieke internet gekoppeld. 10. Bent u het eens met de adoptie-aanbevelingen van de expertgroep aan het Forum Standaardisatie? [paragraaf 4.3 van het expertadvies] De aanbevelingen zijn sterk gericht op de serverkant van het verhaal. Aan de ontvangende zijde dient er evenzo aandacht gegeven te worden aan hoe gebruikers en interne toepassingen kunnen profiteren van de beveiliging die DNSSEC biedt. 11. Is/zijn er volgens u nog andere informatie of overwegingen die aan Pagina 17 van 19

het Forum en College Standaardisatie zou moeten worden meegegeven voor een besluit over het opnemen van deze standaard op de lijst met standaarden?


Nee. Met vriendelijke groet, namens Stichting NLnet Michiel Leenaars

Proxy Laboraties B.V

Aan Logius Bureau Forum Standaardisatie o.v.v. Consultatieprocedure OWMS Postbus 96810 2509 JE Den Haag Betreffende: Reactie openbare consultatie standaarden Leiden, 16 februari 2012, Geachte heer/mevrouw, via deze weg doe ik u de reactie van PROXY Laboratories BV op de, in de huidige openbare consultatie van maart 2012, onderstaande standaarden. Nieuwe standaarden DKIM en DNSSEC Deze beide standaarden zijn reeds jarenlang gevestigde, en stabiele, industriestandaarden, vrijwel alle relevante hard-, en software is hiervoor geschikt, er zijn voldoende referentie-implementaties en testsuites. Het behoeft naar mijn mening geen verdere toelichting, de expertadviezen van deze standaarden zouden naar onze mening gevolgd moeten worden. Deze standaarden zijn zonder meer geschikt voor opname in de Pas-toe-leg-uit lijst. (…)

Pagina 18 van 19

Ik hoop u hiermee voldoende geïnformeerd te hebben en zie de publicaties van de overige reacties op deze openbare consultatie met grote interesse tegemoet. Met vriendelijke groet,


Hans de Raad Manager ICT PROXY Laboratories BV

UWV Graag wil UWV een bijdrage leveren aan de openbare consultatie DKIM en DNSSEC. Onze reactie is met name opgesteld vanuit haalbaarheidsarchitectuurperspectief. UWV onderschrijft de noodzaak standaarden te ontwikkelen en te (her)gebruiken. Een instrument als de pas-toe-of-leg-uit lijst kan hieraan zeker een positieve bijdrage leveren. Minimaal zo belangrijk is de voorbereiding tot het komen tot voorgestelde standaarden. De expertgroep is hierbij een belangrijk medium. Ons commentaar is gericht op de documenten expertadvies DKIM en het expertadvies DNSSEC. Beide overige expertadviezen hebben minder / geen invloed op UWV. Kort samengevat willen we de volgende punten expliciet onder de aandacht brengen: (…) M.b.t. het expertadvies DNSSEC: •

UWV onderschrijft de opname van DNSSEC op de pas-toe-of-leg-uit lijst. Wel wordt de opmerking meegegeven dat het in IPV6 bij Ripe mogelijk wordt voor bedrijven om een IP reeks voor een organisatie te reserveren. Het advies DNSSEC zou in het kader van die ontwikkeling moeten worden gezien.

Eindoordeel UWV onderschrijft de opname van DNSSEC op de pas-toe-of-leg-uit lijst.

Pagina 19 van 19

In de consultatieronde zijn ten aanzien van het expertadvies over de standaard DNSSEC reacties ontvangen van de volgende organisaties:

Recommend Documents