Stuurgroep Standaardisatie Datum: 13 mei 2016 Versie 1.0



Vergelijkbare documenten
FORUM STANDAARDISATIE 20 april 2016 Agendapunt 2E. Forum-advies STARTTLS en DANE Stuknummer 2E Forum-advies STARTTLS en DANE

Geadviseerd wordt om STARTTLS en DANE in combinatie op te nemen op de lijst met open standaarden met de status pas toe of leg uit.

FORUM STANDAARDISATIE

Opname S/MIME 3.2 (standaard voor aanvullende beveiliging van ) op de lijst met open standaarden

FS FORUM STANDAARDISATIE 8 juni 2016 Agendapunt 3. Open standaarden, lijsten Stuknummer 3. Oplegnotitie lijsten. Van: Aan: Bijlagen:

Opname TLS 1.2 op de lijst voor pas toe of leg uit. Stuurgroep Standaardisatie Datum: 2 april 2014 Versie 1.0

FORUM STANDAARDISATIE 11 oktober 2017

FORUM STANDAARDISATIE 22 april 2015 Agendapunt 2: Open standaarden, lijsten Stuk 2A: Advies opname DMARC en SPF op de pas toe of leg uit -lijst

Forum Standaardisatie. Expertadvies STARTTLS en DANE. Datum 16 februari 2016

FS A. FORUM STANDAARDISATIE 16 december 2014 Agendapunt 5. Open standaarden, lijsten Stuknummer 5A. Intake-advies DMARC.

FORUM STANDAARDISATIE 11 oktober 2017

Opname OAuth 2.0-standaard op de lijst met open standaarden. Opname OAuth 2.0-standaard op de lijst met open standaarden

Opname WPA2-Enterprise op de lijst voor pas toe of leg uit

Opname NLCIUS (standaard voor e-factureren) op de lijst met open standaarden

FS B FORUM STANDAARDISATIE 13 JUNI Advies. Agendapunt: 3B Betreft: Intake-advies voor TLS 1.3 Aan: Forum Standaardisatie Van:

Wijziging versiebeheer van Digikoppeling (stelselstandaard voor betrouwbaar berichtenverkeer) op de pas toe of leg uit lijst

Wijziging versiebeheer van Digikoppeling op de pas toe of leg uit lijst

Aan: Forum Standaardisatie Van: Bureau Forum Standaardisatie Datum: 3 april 2018 Versie 1.0 Betreft:

Opname NLCS (standaard voor de uniformering van bouwtekeningen) op de lijst met open standaarden

FS A. A: Beschrijving van de voorgestelde werkwijze B: Toelichting op het MSP en identificatie proces

Forum Standaardisatie. Consultatiedocument IFC. Datum 5 augustus 2011

Opname EPUB 3.0 op de lijst voor pas toe of leg. Stuurgroep Standaardisatie Datum: 3 april 2014 Versie 1.0

FS E. FORUM STANDAARDISATIE 13 december Advies. Agendapunt: 3E Betreft: Intake-advies voor Grip op SSD Aan:

Opname COINS-standaard (uitwisselingsformaat voor bouwinformatie) op de lijst met open standaarden

Forum Standaardisatie. Wilhelmina van Pruisenweg AN Den Haag. Postbus JE Den Haag.

Beveilig verbindingen van mailservers

FS FORUM STANDAARDISATIE 22 april 2015 Agendapunt 2. Open standaarden, lijsten Stuknummer 2. Oplegnotitie lijsten

VIAG THEMADAG State of the art internet beveiliging

Opname PDF/A-2 op de lijst voor pas toe of leg uit. Datum: 23 mei 2012 Versie 1.0

Reacties uit de openbare consultatie STARTTLS en DANE (uitbreiding functioneel toepassingsgebied)

Forum Standaardisatie. Expertadvies DMARC. Datum 12 februari 2015

Doel. Agendapunt: 4. Lijst open standaarden. Stuurgroep open standaarden Datum: Versie 1.0 Stand van zaken Open standaarden

Forum Standaardisatie. Consultatiedocument SIKB0101. Datum 13 februari 2012

Opname HTTPS & HSTS als verplichte standaard op de lijst met open standaarden

Forum Standaardisatie. Samenvatting expertadvies DANE. Datum 12 februari 2014

Advies voor het plaatsen van nieuwe versies van de standaarden SETU en Semantisch Model e-factuur op de pas toe of leg uit -lijst

Consultatieadvies verwijdering NTA 9040 van de lijst met open standaarden

Forum Standaardisatie. Aanvullend onderzoek beoordeling SPF bij Forumadvies DMARC en SPF addendum bij Forumadvies DMARC en SPF. Datum 29 april 2015

HANDLEIDING SMTP DIENST BEDRIJVENWEB NEDERLAND B.V.

Stuurgroep open standaarden Datum: 22 augustus 2012 Versie 1.0

FORUM STANDAARDISATIE 28 oktober 2014 Agendapunt 04. Open standaarden, lijsten Stuk 04D. Forumadvies VISI 1.4

A. Expertadvies adoptie-evaluatie SAML B. Notitie van eid over verwerking adviespunten C. Opzet monitor open standaarden-beleid 2014

Het Forum Standaardisatie wordt geadviseerd om de aangemelde standaard Kerberos niet in behandeling te nemen voor opname op de lijst.

Opname DKIM op de lijst voor pas toe of leg uit. Datum: 23 mei 2012 Versie 1.0

Opname DNSSEC op de lijst voor pas toe of leg uit. Datum: 10 april 2012 Versie 1.0

Registrar Scorecard H2 2018

Forum Standaardisatie. Expertadvies S/MIME 3.2. Datum 22 februari 2018

FORUM STANDAARDISATIE 11 oktober 2017

Opname Digikoppeling 2.0 op de lijst voor pas toe of leg uit

Bescherm domeinnamen tegen phishing

Aanmelding TLS 1.3 voor de pas toe of leg uit -lijst

FS D. FORUM STANDAARDISATIE 16 december 2014 Agendapunt 5. Open standaarden, lijsten Stuknummer 5D. Intake-advies OSI.

Moderne standaarden Veiliger

FS A. Forum Standaardisatie. Adoptieadvies DNSSEC

Forum Standaardisatie. Consultatiedocument <project>

authenticatie

FS C. FORUM STANDAARDISATIE 13 december Advies. Agendapunt: 4C Betreft: Concept intake-advies voor NLCIUS Aan:

ICT en Overheid The Next Generation Internet must be Safe

Rapportage DMARC/SPF/DKIM impactanalyse t.b.v. Forum Standaardisatie

Intentieverklaring Veilige Coalitie

FS FORUM STANDAARDISATIE 19 oktober 2016 Agendapunt 4. Open standaarden, adoptie Stuknummer 4. Oplegnotitie adoptie

Aanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst

FS FORUM STANDAARDISATIE 08 maart Agendapunt 2. Open standaarden, lijsten Stuknummer 2. Oplegnotitie lijsten

Expertadvies OpenAPI Specification-standaard (OAS) en overzicht reacties consultatieronde Aan:

Expertadvies functioneel toepassingsgebieden internet veiligheidstandaarden

Expertonderzoek HTTPS en HSTS

Opname geo-standaarden op de lijst voor pas toe of leg uit en status uitstekend beheer. Forum Standaardisatie Stuurgroep Standaardisatie

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van

Forum Standaardisatie. Expertadvies: Opname MIME op lijst met gangbare standaarden. Datum 4 februari 2011

Stuurgroep open standaarden Datum: 22 augustus 2013 Versie 1.0 Update status van opvolging College-adviezen per standaard

Forum Standaardisatie. Consultatiedocument IPv6. Datum 6 augustus 2010

Concept. Inleiding. Advies. Agendapunt: 04 Bijlagen: - College Standaardisatie

Resultaten van de scan. Open poorten. High vulnerabilities. Medium vulnerabilites. Low vulnerabilities

FORUM STANDAARDISATIE 10 oktober 2018 Agendapunt 3A - Plaatsing TLS 1.3 op pas-toe-of-leg-uit lijst

Opname DNSSEC op de lijst voor pas toe of leg uit. Datum: 23 mei 2012 Versie 1.0

FORUM STANDAARDISATIE Aanmelding DomainKeys Identified Mail (DKIM) Signatures

Gevraagd besluit Aan het Forum wordt gevraagd om in te stemmen met het advies om aan het OBDO de volgende punten voor te leggen:

Halfjaarlijkse meting Informatieveiligheidsstandaarden BFS Begin 2017

Handleiding clients

Forum Standaardisatie. Wilhelmina van Pruisenweg AN Den Haag. Postbus JE Den Haag.

FS FORUM STANDAARDISATIE 28 oktober 2015 Agendapunt 2. Open standaarden, lijsten Stuknummer 2. Oplegnotitie lijsten

, SMTP, TLS & S/MIME

Opname STOSAG op de lijst voor pas toe of leg uit

Nu niet opnemen van Dutch Revit Standards op de lijst voor aanbevolen

FORUM STANDAARDISATIE

Aansluit handleiding Omgevingsloket online. Webservices INREGELOMGEVING (INR) Directie Concern Informatievoorziening

Forum Standaardisatie. Expertadvies functioneel toepassingsgebieden internet- en beveiligingsstandaarden

Forum Standaardisatie. Forumadvies voor MTOM. Datum 4 oktober 2013

FS A. Advies. Pagina 1 van7

Zorgbrede aanpak voor veiliger mailen

DigiD SSL. Versie Datum 16 augustus 2010 Status Definitief

FORUM STANDAARDISATIE FS

Opname eherkenning op de lijst voor. Datum: 26 oktober 2012 Versie 0.9

Opname SIKB0102 standaard op de lijst van open standaarden.

Agendapunt: 3A Expertadvies NLRS-standaard en overzicht reacties consultatieronde. Stuurgroep Standaardisatie Datum: 20 november 2017 Versie 1.

FS FORUM STANDAARDISATIE 11 oktober Agendapunt 3. Open standaarden, lijsten. Stuurgroep open standaarden

Transcriptie:

FS 160608.3D Forum Standaardisatie www.forumstandaardisatie.nl forumstandaardisatie@logius.nl Bureau Forum Standaardisatie gehuisvest bij Logius Postadres Postbus 96810 2509 JE Den Haag Bezoekadres Wilhelmina van Pruisenweg 52 FORUM STANDAARDISATIE Agendapunt: FS 160608.3D Betreft: Aanvullend onderzoek SMTP STS Aan: Forum Standaardisatie Van: Stuurgroep Standaardisatie : 13 mei 2016 Versie 1.0 2595 AN Den Haag Bij bezoek aan Logius is legitimatie verplicht Aanleiding en achtergrond Tijdens de openbare consultatie van STARTTLS en DANE is een voorstel voor een nieuwe standaard ingediend bij de Internet Engineering Task Force (IETF), ondersteund door de grotere mailplatformen (Gmail, Yahoo, Microsoft). Het voorstel beschrijft een standaard voor de totstandkoming van versleutelde verbindingen tussen mailservers, waarbij het gebruik van DNSSEC niet noodzakelijk is. Deze (concept)standaard kan gezien worden als potentiële concurrent van DANE, en kan een grote impact hebben op de adoptie van STARTTLS en DANE. Het Forum Standaardisatie heeft zodoende de opdracht gegeven om aanvullend onderzoek te doen naar SMTP STS en de impact hiervan alvorens een besluit te nemen over de opname van de combinatie STARTTLS en DANE op de lijst met open standaarden. - Betrokkenen en proces In dit onderzoek is gekeken naar het voorstel voor de standaard SMTP STS, zoals eind maart ingediend bij IETF. Ook is het voorstel beoordeeld tegen de toetsingscriteria voor de lijst met open standaarden. Deze notitie geeft de uitkomsten van dit onderzoek kort weer en sluit af met een advies aan het Forum Standaardisatie. Een eerste conceptversie van dit advies is aan de leden van de expertgroep STARTTLS en DANE en het Bureau Forum Standaardisatie gestuurd met het verzoek om een reactie op het advies. Na verwerking van deze reacties is het advies ingediend bij het Bureau Forum Standaardisatie. Consequenties en vervolgstappen Naar aanleiding van het onderzoek kan geconcludeerd worden dat SMTP STS en de combinatie STARTTLS en DANE een overlappend functioneel toepassingsgebied hebben. Het voorstel voor SMTP STS is echter nog conceptueel en het ontwerp voor de standaard is (nog) niet waterdicht. Gezien deze factoren wordt het Forum Standaardisatie geadviseerd om de ontwikkelingen omtrent SMTP STS in de gaten houden, maar de besluitvorming omtrent de opname van STARTTLS en DANE wel voort te zetten. Mede gezien het belang van de standaarden. Pagina 1 van 7

Gevraagd besluit Het Forum Standaardisatie wordt gevraagd om: 1. kennis te nemen van de standaard SMTP STS; 2. kennis te nemen van de beoordeling van SMTP STS op de toetsingscriteria; 3. in te stemmen met het advies om de ontwikkelingen rondom SMTP STS in de gaten te houden en de besluitvorming omtrent de opname van STARTTLS en DANE voort te zetten. Ad 1 SMTP STS Het voorstel voor STMP STS is eind maart 2016 als Internet Draft bij de Internet Engineering Task Force (IETF) ingediend en is geldig tot 20 september 2016. Het huidige voorstel is voor een breed publiek beschikbaar voor informele beoordeling en becommentariëring. Internet Drafts hebben geen formele status, en kunnen op elk moment gewijzigd of verwijderd worden. SMTP Strict Transport Security (SMTP STS) is een standaard voor het opzetten van versleutelde verbindingen tussen mailservers met als doel het upgraden van een onbeveiligde verbinding over een onvertrouwd netwerk naar een versleutelde verbinding over een onvertrouwd netwerk. Voor deze SMTP STS verbindingen is het niet verplicht om DNSSEC te gebruiken, maar het is wel mogelijk. STMP STS werkt voor zowel verzendende als ontvangende mailservers. Ontvangende mailservers moeten voor elk van de e-domeinnaam een STS-beleid in een DNS-record publiceren. Het STS-record geeft dan kort gezegd aan welke acties uitgevoerd moeten worden in een bepaalde periode. In dit STS-record wordt de volgende informatie gepubliceerd: - de vraag of e-mail van de domeinnaam alleen via TLS mag worden verzonden, - een lijst met hostnamen van mailservers die e-mail voor het betreffende domein mogen ontvangen, - het beleid voor het te gebruiken authenticatiemechanisme (via web PKI of DNSSEC), - het certificaat voor het gebruikte authenticatiemechanisme (via web PKI of DANE), - de (geldigheids)duur van dit beleid. Dit is de termijn waarbinnen mailservers het beleid moeten hanteren, - optioneel: een e-mailadres waar verzendende mailservers geaggregeerde feedback kunnen verzenden, bijvoorbeeld over foutmeldingen. Verzendende mailservers moeten het STS-beleid van de ontvangende mailserver controleren. Het hiervoor voorgestelde proces bij het verzenden van een e-mail is als volgt: 1. de verzendende mailserver controleert of er op de server al een beleid van de ontvangende mailserver bekend is. Als dit niet het geval is kan het beleid via de Domain Name Server (DNS) worden opgehaald, 2. de verzendende mailserver valideert de ontvangende mailserver. Als de ontvangende mailserver geldig is kan de e-mail worden afgeleverd, 3. Als de ontvangende mailserver niet geldig is dient op basis van het STS-beleid een van de volgende acties uitgevoerd te worden: a. het versturen van een rapportage aan de ontvangende mailserver over de mislukte poging om de e-mail via een TLS-verbinding af te leveren. De e-mail wordt wel verzonden, Pagina 2 van 7

b. wanneer in het beleid gespecificeerd is dat e-mail alleen via een TLSverbinding verzonden mag worden dient (via de DNS) gecontroleerd te worden of er nieuw beleid beschikbaar is. Indien dit het geval is kan het nieuwe beleid worden geauthenticeerd en het oude beleid overschreven. Vervolgens kan opnieuw worden geprobeerd de e-mail te verzenden (vanaf stap 1). Als deze nieuwe poging niet slaagt wordt de e-mail niet verzonden. De verzendende mailserver informeert de ontvangende partij per e-mail over de mislukte afleverpoging. SMTP STS versus DANE in combinatie met STARTTLS 1 Het doel van SMTP STS met het STS-beleid en het DANE TLSA-record is hetzelfde: het upgraden van een onbeveiligde verbinding over een onvertrouwd netwerk (opportunistische encryptie) naar een versleutelde verbinding over een onvertrouwd netwerk (verplichte encryptie). Hierdoor is het voor aanvallers niet meer mogelijk om berichtenverkeer af te luisteren of te manipuleren. Beide standaarden maken voor de authenticatie van de verzendende en de ontvangende partij gebruik van gepubliceerde certificaten die door certificaatautoriteiten (CA s) binnen het PKI-stelsel zijn uitgegeven. Aanvullend maakt DANE het mogelijk om door middel van een met DNSSEC beveiligd DNSrecord extra informatie bovenop de offline certificaten uit te reiken. Dit DNS-record kan worden gezien als een digitale vingerafdruk. SMTP STS maakt naast de eerder genoemde certificaten gebruik van Trust-on-First-Use (TOFU-principe) om onderschepping te voorkomen. Dit principe houdt in dat wanneer een verzendende mailserver voor de eerste keer een verbinding op wil zetten met een nieuwe ontvangende mailserver, de verzendende mailserver wordt gevraagd om een sleutel te accepteren, op te slaan en voor een bepaalde periode te gebruiken. Bij toekomstige verbindingen kan, voor de in het beleid bepaalde periode, door middel van deze sleutel de ontvangende mailserver geauthenticeerd worden. Wanneer de sleutel is veranderd wordt een waarschuwing gegeven. Nadeel van deze methode is dat de sleutel voor elke unieke verbinding opgeslagen moet worden. Dit is met name voor kleinere mailproviders een intensief proces. Daarnaast kan de sleutel bij de eerste verbinding gemanipuleerd worden, waardoor het voor de verzendende mailserver lijkt alsof hij verbonden is met de juiste mailserver, maar dit in werkelijkheid niet is. Hierdoor kan de standaard een vals gevoel van veiligheid geven. Aanvullend biedt SMTP STS een mechanisme voor fout-rapportages. Dit maakt het mogelijk om bijvoorbeeld misbruik inzichtelijk te maken. Nadeel is echter dat deze rapportageberichten via de onbeveiligde verbinding worden gestuurd, en zodoende ook gemanipuleerd kunnen worden. Bij het gebruik van RFC 7672 (DANE over SMTP/STARTTLS) wordt afgeraden om e- mail te versturen wanneer geen beveiligde verbinding tot stand kan worden gebracht. Het voorstel voor SMTP STS doet hier geen uitspraak over. 1 IETF RFC 7672 (https://tools.ietf.org/html/rfc7672). Pagina 3 van 7

DANE over SMTP/STARTTLS SMTP STS Voordelen - Gestandaardiseerd. - Kan direct gebruikt worden - Geen additionele hardware nodig bij gebruik. - Directe koppeling tussen verzendende en ontvangende mailserver. - Ondersteunt door grote Amerikaanse mailproviders - Vereist geen werkende DNSSEC-implementatie. - Mechanisme voor foutrapportage. Nadelen - Vereist gebruik van DNSSEC. - Nog niet door alle grote Amerikaanse mailproviders geadopteerd. - Standaard is nog in ontwikkeling. - Bij eerste contact kan de sleutel onderschept en/of gemanipuleerd worden. - Organisaties kunnen zelf bepalen of e-mails over een onbeveiligde verbinding mogen worden verstuurd. - Extra webserver (met PKI-certificaat) naast DNS en mailserver noodzakelijk. - Beheerlast voor kleine(re) mailproviders is groot (door policy caching). Ad 2 Beoordeling SMTP STS op toetsingscriteria Toegevoegde waarde SMTP STS kent een overlappend functioneel toepassingsgebied met STARTTLS en DANE. Overigens kunnen de standaarden wel naast elkaar gebruikt worden en zijn ze technisch niet met elkaar in conflict: Inkomende en verzendende mailservers passen SMTP STS en bijbehorend beleid toe zodat er een versleutelde verbinding over een onvertrouwd netwerk (zoals internet) opgezet kan worden. Dit voorkomt dat aanvallers het mailverkeer kunnen afluisteren (passieve aanvallers) en/of kunnen manipuleren (actieve aanvallers). Het Forum staat voor betrouwbare berichtenuitwisseling. Dit is belangrijk gezien het feit dat met de toenemende digitalisering ook de dreiging van digitale aanvallen toeneemt. Via digitale (economische) spionage kan in een kort tijdsbestek grote hoeveelheden informatie op grotendeels anonieme en simultane wijze worden verzameld. Ook kan informatie worden aangepast. De Nederlandse overheid moet vertrouwelijke informatie beschermen tegen afluisteren door aanvallers, zoals vijandelijke partijen en statelijke actoren. Hieronder valt ook de communicatie tussen overheidspartijen, tussen de overheid en bedrijven, en tussen overheden en burgers. Pagina 4 van 7

Een organisatie is in de meeste gevallen zowel verzendende partij als ontvangende partij. Dit betekent dat een organisatie als ontvangende partij een STS-beleid moet opstellen en publiceren en dat de verzendende partij dit beleid moet opvolgen. Dit betekent voor een verzendende partij dat het beleid van de ontvangende partij opgevraagd en opgeslagen moet worden. Daarbij moet de verzendende partij, afhankelijk van de (geldigheids)duur van het beleid, periodiek het beleid updaten. Dit is voor met name kleinere mailproviders een intensief proces, aangezien zij een kleinere doelgroep bedienen en daardoor niet dagelijks met alle mailservers wereldwijd communiceren. Een nadeel van SMTP STS is dat de werking van de standaard niet volledig waterdicht is. De sleutel kan bij de eerste verbinding gemanipuleerd worden, waardoor het voor verzendende mailservers lijkt alsof hij verbonden is met dit juiste mailserver, maar dit in werkelijkheid niet is. Dit kan een vals gevoel van veiligheid geven. Daarnaast kan door het gebruik van hierboven beschreven TOFUprincipe misbruik ongemerkt blijven. In tegenstelling tot de combinatie van STARTTLS en DANE stelt SMTP STS het gebruik van DNSSEC niet verplicht. Gebruikers kunnen voor de authenticatie van mailservers kiezen om dit door middel van WebPKI (X509-standaard) of DNSSEC te doen. Het gebruik van DNSSEC heeft in Nederland met name bij de ontvangende kant nog geen grote omvang. Uit onderzoek van SIDN in 2012 is gebleken dat de implementatie van DNSSEC belemmert wordt door het gebrek aan kennis bij registrars 2, gebrek aan vraag bij eindgebruikers, gebrek aan goede ondersteuning in de software en userinterfaces en investerings- en operationele kosten 3. Hierdoor is best de kans dat ontvangende partijen die SMTP STS willen implementeren zullen kiezen voor authenticatie door middel van WebPKI. Dit zou zodoende kunnen leiden tot een stagnatie van het gebruik van DNSSEC. Open standaardisatieproces De standaard SMTP STS is op dit moment enkel nog een papieren voorstel en geen werkende standaard. De standaard is zodoende ook nog niet in beheer bij een standaardisatieorganisatie. Het voorstel voor SMTP STS is eind maart als Internet Draft ingediend bij de Internet Engineering Task Force (IETF) door de grotere Amerikaanse e-mailproviders (Google, Yahoo, Microsoft e.a.) en is geldig tot 20 september 2016. Het huidige voorstel is voor een breed publiek beschikbaar voor informele beoordeling en becommentariëring. Internet Drafts hebben geen formele status, en kunnen op elk moment gewijzigd of verwijderd worden. Tijdens eerdere toetsingsprocedures is geconcludeerd dat het standaardisatieproces van IETF voldoende open is. IETF kent goed gedocumenteerde en open beheerprocedures die gratis zijn de downloaden op de website van IETF. Er is geen lidmaatschap, het beheerproces en de besluitvorming hieromtrent is open en transparant. Belanghebbenden kunnen zich kosteloos aanmelden voor de diverse groepen die werken aan de (door)ontwikkeling van standaarden die bij IETF in beheer zijn. IETF is een internationale standaardisatieorganisatie die onder andere ook DKIM, SPF, DNSSEC, STARTTLS & DANE (RFC 7672) en TLS in beheer heeft. 2 Een registrar is een bedrijf dat in opdracht van bedrijven, instellingen of personen een domeinnaam registreert. 3 https://www.dnssec.nl/cases/gebrek-aan-kennis-is-belangrijkste-belemmering-voor-implementatie-dnssec.html. Pagina 5 van 7

Draagvlak SMTP STS is op dit moment nog een papieren voorstel. Hierdoor hebben aanbieders en gebruikers nog geen ervaring op kunnen doen met het ondersteunen, implementeren en gebruiken van de standaard. Er zijn op dit moment geen (positieve) signalen over het gebruik van de standaard op korte termijn. Het voorstel voor de standaard is opgesteld door medewerkers van een aantal (grote) (web)mailproviders, namelijk Google (Gmail), Microsoft (Outlook en Live) en Yahoo. Deze mailproviders bedienen wereldwijd een groot aantal gebruikers. Opname bevordert adoptie Dit is niet expliciet getoetst, maar er is geen wettelijke verplichting tot het gebruik van de standaard. Gezien het gegeven dat de standaard feitelijk gezien nog niet bestaat is het niet mogelijk om uitspraak te doen of opname de adoptie bevordert. Wel kan opname op de lijst de adoptie van DNSSEC belemmeren. Ad 3 Advies Afgaand op het voorstel voor SMTP STS en de toetsing van de standaard op de toetsingscriteria is een aantal conclusies te trekken: - het is goed nieuws dat grote mailproviders bezig zijn met de beveiliging van e-mailverkeer, - SMTP STS is echter vooral bedoeld voor grote (Amerikaanse) mailproviders. Voor kleine(re) mailproviders is het gebruik van de standaard een intensief, en daarmee kostbaar proces, - het voorstel voor SMTP STS is nog niet op alle onderdelen volledig uitgewerkt of dekkend, - het ontwerp van SMTP STS is niet waterdicht. Het is mogelijk om bij de totstandkoming van de eerste verbinding de sleutel te manipuleren, waardoor ook berichtenverkeer kan worden gemanipuleerd, - de introductie van SMTP STS kan mogelijk het gebruik van de combinatie STARTTLS en DANE negatief beïnvloeden al conflicteren de standaarden technisch niet met elkaar, - de introductie van SMTP STS kan een negatieve invloed hebben op de implementatie van DNSSEC. - het is op dit moment niet duidelijk of, en wanneer, SMTP STS een officiële standaard wordt. Gezien de huidige premature status van het voorstel van de standaard is het voor de overheid niet wenselijk om een afwachtende houding aan te nemen. STARTTLS EN DANE zijn beide ontwikkelde standaarden in beheer bij een gerenommeerde standaardisatieorganisatie en kunnen daadwerkelijk al geïmplementeerd worden. Opname van STARTTLS in combinatie met DANE maakt het mogelijk om e-mailverkeer tussen overheden, tussen overheden en bedrijven en tussen overheden en burgers via een versleutelde verbinding mogelijk te maken. Ook is opname op de lijst een stimulans voor mailproviders om DANE en DNSSEC te ondersteunen. Pagina 6 van 7

Het Forum Standaardisatie wordt daarnaast geadviseerd om de ontwikkelingen rondom SMTP STS in de gaten te houden. Wanneer SMTP STS een ontwikkelde standaard is dient de relatie tussen SMTP STS en STARTTLS en DANE opnieuw geduid te worden om een meer omvattend beeld te kunnen schetsen. Het advies is dan ook om deze ontwikkeling nauw te volgen en waar mogelijk te participeren in de doorontwikkeling van de standaard. De aangewezen partij hiervoor is het NCSC, conform haar Cyber Security strategie 4. Betrokken personen bij de totstandkoming van dit advies - Experts betrokken bij de toetsing van STARTTLS en DANE. 4 https://www.ncsc.nl/english/current-topics/national-cyber-security-strategy.html Pagina 7 van 7