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

Transcriptie

1 Bezoekadres: Wilhelmina v Pruisenweg AN Den Haag 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, :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, PD- FA2, 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

2 ( ) Opname DNSSEC 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

3 BKWI Publieke Consultatie DNSSEC Inhoudsopgave 1. Inleiding 4 2. Onze bevindingen t.a.v. het expert-adviesdocument 4 3. Aanvullende Adviezen aan het Forum 12 Auteur: ir. Willem Kossen, ICT-Architect document: 11/3/2012 Versie: 1 Status: (Concept) afdruk: Pagina 3 van 19

4 Inleiding Met interesse hebben we kennisgenomen van het expertadvies omtrent de standaard DNSSEC aan Forum. 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! ( ) Onze bevindingen t.a.v. het expert-advies Pagina 4 van 19

5 Algemene bevindingen 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 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 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

6 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 over- Pagina 6 van 19

7 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

8 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 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 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

9 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 arbeidsintensiever 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 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

10 onbeschikbaarheid van hun zones hebben meegemaakt als gevolg van deze probleempjes. 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 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, 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 din- Pagina 10 van 19

11 gen die je kunt doen om beetjes veiligheid aan DNS toe te voegen, zoals de sourceport-randomization uit 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 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

12 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

13 EL&I From: Rood, drs. P.H. (Pieter) Sent: Thursday, February 23, :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 voor standaardstelling overgenomen, dus akkoord. 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

14 KvK aan van Memo Forum Rob Spoelstra kenmerk datum 13 maart 2012 onderwerp Openbare consultatie DNSSEC Hierbij onze reactie op het Consultatiedocument DNSSEC van 13 februari 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 voorzien van een inhoudelijk relevante toelichting). Nee. 2. Bent u het eens met het door de expertgroep geadviseerde functionele toepassingsgebied? 3. Bent u het eens met het door de expertgroep geadviseerde organisatorische werkingsgebied? 4. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het open standaardisatieproces? 5. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de toegevoegde waarde? 6. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het draagvlak? 7. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de bevordering van de adoptie door opname op de lijst? 8. Bent u het eens met de samenvatting van de overwegingen van de expertgroep? 9. Bent u het eens met het advies van de expertgroep aan het Forum m.b.t. opname van de standaarden op de lijst? Pagina 14 van 19

15 10. Bent u het eens met de adoptie-aanbevelingen van de expertgroep aan het Forum? 11. Is/zijn er volgens u nog andere informatie of overwegingen die aan het Forum en College 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, :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 voorzien van een inhoudelijk relevante toelichting). Nee. 2. Bent u het eens met het door de expertgroep geadviseerde functionele Pagina 15 van 19

16 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] 4. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het open standaardisatieproces? [paragraaf 3.1 van het expertadvies] 5. Bent u het eens met de constateringen en conclusies van de expertgroep inzake de toegevoegde waarde? [paragraaf 3.2 van het expertadvies] 6. Bent u het eens met de constateringen en conclusies van de expertgroep inzake het draagvlak? [paragraaf 3.3 van het expertadvies] 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] 8. Bent u het eens met de samenvatting van de overwegingen van de Pagina 16 van 19

17 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? [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

18 het Forum en College 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 o.v.v. Consultatieprocedure OWMS Postbus 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

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