Een maturitymodel voor moderne internetstandaarden
Doelen stellen en keuzen maken
Samen met een heleboel andere nationale en internationale organisaties betrokken bij onze internetinfrastructuur maken wij ons al jaren hard voor de adoptie van moderne internetstandaarden. Het gaat dan bijvoorbeeld om DNSSEC, IPv6, SPF/DKIM/DMARC en DANE. Zoals je ziet zijn dit vooral veiligheidsgerelateerde standaarden, maar we pushen ook IPv6 wat gericht is op de onderliggende infrastructuur. Over het belang van een veiliger internet kunnen we haast dagelijks in het nieuws lezen. En met de problematiek van de beperkte IPv4-adresruimte worstelen we inmiddels al decennia. Wat nog ontbrak bij het stimuleren van al die moderne standaarden is de onderlinge samenhang ervan, onderlinge afhankelijkheden en prioriteiten ten opzichte van elkaar. Het budget en de capaciteit van infrastructuurbeheerders en -aanbieders is immers beperkt. In dit artikel presenteren we een maturitymodel dat de belangrijkste internetstandaarden in een matrix op een rij zet.
Figuur 1. Een maturitymodel voor moderne internetstandaarden.
De indeling
Op de verticale dimensie zie je gekleurde lagen die de verschillende niveaus weergeven. De onderste laag (rood/oranje) is wat we 'old-school' hebben genoemd. Daar vind je de klassieke en veelal verouderde internetstandaarden die inmiddels echt een probleem vormen. Voor sommige daarvan zijn goede uitbreidingen en aanvullingen beschikbaar – denk aan DNSSEC voor DNS, en STARTTLS, SPF/DKIM/DMARC en DANE voor mail. Andere standaarden moeten vervangen worden door nieuwe standaarden – zoals IPv6 in plaats van IPv4, en HTTPS in plaats van HTTP. De meeste van die uitbreidingen en nieuwe standaarden waar we nu zo hard aan trekken bevinden zich in de groene laag. Onderaan ('modern') tref je DNSSEC en (dual-stack) IPv6, die je inmiddels echt wel moet gebruiken of heel snel zou moeten implementeren. In het midden zien we vooral beveiligingsstandaarden, waarvan er veel voortbouwen op de cryptografische infrastructuur van DNSSEC. Bovenaan vind je nog relatief nieuwe en onbekende beveiligingsstandaarden, zoals DoH/DoT, RPKI, NTS [1, 2] en SSHFP, die we daar hebben aangeduid als 'state-of-the-art'.
Helemaal bovenaan in de blauwgroene laag staat tenslotte een aantal 'future-proof' standaarden, of combinaties van standaarden, die de meesten nu misschien niet direct als project zouden implementeren, maar die vooral voor wat betreft IPv6 wel heel belangrijk zijn om als doel in de gaten te houden bij het opzetten van roadmaps en migratietrajecten. Daarnaast hebben we het model in tweeën verdeeld op de horizontale dimensie. Aan de linkerkant staan de beveiligingsstandaarden voor respectievelijk web, mail en de eindgebruiker. Aan de rechterkant staan de infrastructurele standaarden (IPv6 en co) voor respectievelijk de server-zijde en de eindgebruiker – hoewel we daar een klein beetje smokkelen met RPKI die toch weer primair een beveiligingsstandaard is (zij het voor internetinfrastructuur).
De keuze en rangschikking
De plaatsing van de standaarden op de verschillende niveaus is afhankelijk van twee zaken. Allereerst het belang van een standaard ten opzichte van de andere standaarden in dezelfde kolom, en ten opzichte van de andere standaarden (of dezelfde) in de kolommen eromheen. Daarnaast zijn er harde en minder harde afhankelijkheden tussen standaarden onderling, vooral bij die standaarden die voortbouwen op DNSSEC. Zo is DANE een uitbreiding op SPF en/of DKIM. Voor alle drie is DNSSEC wel aangeraden maar niet verplicht. Terwijl DNSSEC voor DANE wel verplicht is, omdat DANE gebruikmaakt van de vertrouwensketen die DNSSEC naar het root-domein opbouwt. De keuze welke standaarden wel en niet in dit model op te nemen heeft wat meer moeite gekost. Uitgangspunt daarbij was om in ieder geval die standaarden op te nemen die op de 'pas toe of leg uit' (ptolu)-lijst van Forum Standaardisatie staan en door het Platform Internetstandaarden – waarin SIDN ook participeert – worden gepusht en getest via de Internet.nl portal. Als je dat naloopt zie je dat DNS-over-HTTPS (DoH) en DNS-over-TLS (DoT) overblijven, tezamen met RPKI. Die eerste twee hebben we in dit model opgenomen omdat ze de afgelopen paar jaar razendsnel zijn opgekomen. Die laatste staat erbij omdat er bij het Platform Interstandaarden nu wordt nagedacht om deze aan de Internet.nl portal toe te voegen. De reden dat we een vraagteken bij 'DoT' en 'DANE voor web' hebben gezet, is dat we er nog niet zeker van zijn dat het wat gaat worden met deze twee standaarden. DoT wordt wel geïmplementeerd, maar is lang niet zo populair als DoH. En waar DANE voor mail de laatste tijd flink in de lift zit, komt DANE voor het web helemaal niet van de grond. Het lijkt er op dat de certificaten van Let's Encrypt dat gat inmiddels hebben opgevuld. Andere standaarden waar je nog aan zou kunnen denken zijn bijvoorbeeld OpenPGP, het Signal Protocol en ZRTP, (voor end-to-end versleuteling (E2EE) van respectievelijk mail/files, berichten en internet-telefonie), en OpenVPN en WireGuard (voor het opzetten van VPN-verbindingen). Maar die zitten toch wat verder af van de generieke internet-basisinfrastructuur.
Doelen stellen en keuzen maken
We hopen dat je dit model kunt gebruiken om op een hoger niveau te kijken naar waar je staat met je infrastructuur, doelen te stellen voor wat betreft het niveau waar je heen wilt, en keuzen te maken waar te beginnen (vergelijk project portfoliomanagement), met inachtneming van onderlinge afhankelijkheden. Een van de zaken waar we zelf aan denken is om dit model te gebruiken om alle informatie die we in de loop der jaren over moderne internetstandaarden hebben gepubliceerd onder één paraplu te brengen. Maar dat is op dit moment alleen nog maar een idee. Voor een uitgebreid overzicht van de hands-on artikelen over zowel de DNSSEC-ondertekening op autoritatieve DNS-servers als de validatie op (caching) resolvers verwijzen we je naar dit overzichtsartikel en onze DNSSEC-hoek. Bovendien hebben we onlangs vier uitgebreide hands-on artikelen gepubliceerd over de implementatie van SPF/DKIM/DMARC en DANE op respectievelijk de Postfix en Exim mail servers:
Daarbij kun je ook deze handige checklist gebruiken:
Tenslotte: feedback op het maturitymodel is uiteraard van harte welkom.