Het Forum Standaardisatie wil diverse nieuwe standaarden aan de pas-toe-of-leg-uit-lijst (ptolu) toevoegen. Daaronder bevinden zich ook STARTTLS en DANE voor uitgaande mail.
Toevoeging aan de lijst betekent dat (semi-)overheidsorganisaties straks min-of-meer verplicht zijn deze standaarden te implementeren. Concreet moeten alle relevante standaarden die op de ptolu-lijst staan worden opgenomen in aanbestedingen boven de 50.000 euro, tenzij er goede argumenten zijn om dat niet te doen.
Het drietal TLS/STARTTLS/DANE zorgt voor een veilige — dat wil zeggen cryptografisch beschermde — verbinding voor het transport van mail-berichten. Daarbij wordt voortgebouwd op de bestaande DNSSEC-infrastructuur: RFC 7672 stelt het gebruik van DNSSEC bij DANE verplicht.
Vastpinnen TLS-certificaat
Veel SMTP-servers (MX gateways) bieden al de mogelijkheid tot het gebruik van TLS, dezelfde beveiliging als gebruikt bij HTTPS voor het web. Afleverende mail-systemen kunnen dan het STARTTLS-commando gebruiken om hun TCP-verbinding op te waarderen naar TLS. Omdat clients dit niet verplicht zijn en een man-in-the-middle de STARTTLS capability van een server makkelijk kan verstoppen voor de client (in een zogenaamde downgrade-aanval) is STARTTLS op zichzelf nog geen complete oplossing.
Door het TLS-certificaat van de mail service (op TCP-poort 25) vast te leggen (middels een hash) in een DNSSEC-beveiligd TLSA record weet een client zeker dat de betreffende server TLS ondersteund. De Postfix mail server (na Exim de meest gebruikte MTA) kan zo geconfigureerd worden dat deze DANE-authenticatie doet alvorens mail af te leveren bij een MX gateway.
Opportunistisch protocol
Cruciaal verschil tussen TLS voor mail en TLS voor web (HTTPS) is dat het gebruik van 'https' in een URL impliceert dat TLS gebruikt moet worden en dat daarvoor ook een aparte TCP-poort (nummer 443) beschikbaar is. Voor mail blijft het gebruik van TLS door de client echter optioneel, waarmee DANE/TLS voor mail een zogenaamd opportunistisch protocol blijft. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS-ondersteuning en TLSA records aanbiedt moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Zo wordt gewaarborgd dat het afleveren van berichten — waar immers geen mens aan te pas komt — zo veel mogelijk autonoom doorgang kan vinden.
Er was door IANA ooit wel een speciale TCP-poort (nummer 465) gereserveerd voor SMTP-over-SSL (SMTPS), maar die is nooit gestandaardiseerd en inmiddels ook weer toegewezen aan een heel andere service. Mail-adressen bevatten immers geen aanduiding voor een al-dan-niet-beveiligd transport, en mail-systemen hebben geen mogelijkheid om direct met de afzender te interacteren, anders dan via een bounce. Vandaar dat we via nu DANE/STARTTLS het transport "zo veel mogelijk" proberen te beveiligen.
REQUIRETLS
Er wordt overigens wel gewerkt aan het oplossen van dit probleem. Deze Internet Draft introduceert een REQUIRETLS sleutelwoord/capability en een RequireTLS mail header. Het REQUIRETLS sleutelwoord kan door afleverende systemen worden gebruikt om aan te geven dat het betreffende bericht alleen over een TLS-beveiligde verbinding mag worden overgedragen — hier is de beveiliging van het transport dus belangrijker dan de aflevering van het bericht. Ontvangende servers gebruiken hetzelfde sleutelwoord als capability om clients te laten weten dat zij REQUIRETLS inderdaad ondersteunen en "beloven" daarmee ook het verdere transport alleen via beveiligde kanalen te zullen doen.
De verzender van een bericht kan de RequireTLS header gebruiken om aan te geven hoe belangrijk hij een beveiligd transport vindt. Hij kan daarmee bijvoorbeeld expliciet toestaan dat een bericht ook over niet-beveiligde verbindingen mag worden getransporteerd als dat niet anders kan — de aflevering van het bericht is hier dus belangrijker dan de beveiliging van het transport.
MTA Strict Transport Security
Een ander protocol in ontwikkeling is MTA Strict Transport Security (MTA-STS). Daarbij worden de MX gateways voor een domein en of zij STARTTLS verplichten vastgelegd in een policy-bestand. Dit protocol maakt wel gebruik van een DNS TXT record om aan te geven dat er een policy is, maar de policy zelf moet via HTTPS opgehaald worden. Voor dat laatste wordt dus meegelift op het bestaande systeem van CA-certificaten voor het web, en het is de bedoeling om op termijn voor mail-systemen een vergelijkbare hiërarchie van CA's op te bouwen.
Het idee van MTA-STS is dat afleverende mail-systemen de policies langdurig (weken of maanden lang) bewaren en voor de bezorging van mail-berichten checken (valideren) of de MX gateways die ze via DNS toegestopt krijgen inderdaad geldig zijn. Om de kans op een MITM-aanval te verkleinen moet je wel de al opgeslagen policies elke dag of week pro-actief verversen onafhankelijk van eventuele mail-bezorging. Voor het testen van een MTA-STS-configuratie kun je hier terecht.
Voor de rapportage van problemen wordt een apart mechanisme ontwikkeld — SMTP TLS Reporting (TLSRPT) — welke ook voor DANE gebruikt kan worden. De implementatie ervan is vergelijkbaar met het rapportagemechanisme van DMARC.
MTA-STS is een initiatief vanuit Google nadat men daar zag dat de adoptie van DNSSEC niet erg opschoot — zoals gezegd een vereiste voor het gebruik van DANE. Dit protocol werkt daarom om DNSSEC heen, maar biedt daardoor ook minder bescherming dan DANE: De inhoud van het policy-bestand is feitelijk een kopie van de MX RRset met een lange TTL. Door die informatie langdurig te bewaren kunnen MX redirect- en STARTTLS downgrade-aanvallen gedetecteerd worden. Het nadeel van deze aanpak is dat MTA-STS uitgaat van een geldige policy die eerder (zonder de bescherming van DNSSEC) werd opgehaald ("trust on first use") — net als het HSTS-protocol. En waar DANE een specifiek certificaat (of een keten) van een anker voorziet, bouwt MTA-STS opnieuw een CA-gebaseerd certificaten-systeem op, met alle problemen die we al kennen van het web. Tegelijkertijd doet MTA-STS expliciet geen afbreuk aan DANE: als DANE aanwezig is maar niet gevalideerd kan worden, dan mag je ook een MX gateway die wel valideert volgens MTA-STS niet gebruiken.
Expertonderzoek
"In 2015 zijn STARTTLS en DANE alleen voor inkomende mail verplicht gesteld omdat er nog niet veel marktondersteuning was voor uitgaande mail, " zegt Han Zuidweg, Senior Advisor bij Logius (waar het Forum Standaardisatie is ondergebracht). " Voor inkomende mail was die ondersteuning er toen wel al."
"De toetsingsprocedure voor STARTTLS en DANE voor uitgaande mail is net begonnen. We benaderen hiervoor de mensen die betrokken waren bij het expertonderzoek in 2015. Als er anderen zijn die graag aan dit onderzoek willen deelnemen (bijvoorbeeld omdat hun organisatie geraakt wordt door de verplichting) dan kan dat. We verwachten binnen een maand het expertadvies compleet te hebben. Op 6 augustus gaat dat advies dan in openbare consultatie, zodat iedereen daar commentaar en feedback op kan geven."
Adoptie
DNSSEC zelf staat net als STARTTLS en DANE voor inkomende mail al langer op de ptolu-lijst.
Onlangs werd door het Overheidsbrede Beleidsoverleg Digitale Overheid (OBDO) de ambitie uitgesproken om eind 2019 bij alle overheidsorganisaties server-side STARTTLS en DANE geïmplementeerd te hebben. Eerder werden vergelijkbare doelstellingen uitgesproken voor onder andere DNSSEC, DKIM, SPF en DMARC, maar de adoptie daarvan ging minder snel dan gehoopt. Als STARTTLS en DANE ook voor uitgaande mail aan de pas-toe-of-leg-uit-lijst (ptolu) worden toegevoegd, dan zal ook daarvoor een doelstelling uitgesproken worden.
STARTTLS Everywhere
Er zijn op dit moment allerlei initiatieven om het gebruik van STARTTLS te bevorderen. Zo werken wij bij SIDN zelf aan een uitbreiding van de Registrar Scorecard met een incentive-regeling voor het gebruik van STARTTLS, DKIM, SPF en DMARC. Dat betekent dat registrars die hun .nl-domeinnamen van deze beveiligingsstandaarden voorzien daarvoor een korting krijgen.
In navolging van het populaire Let's Encrypt lanceerde de Electronic Frontier Foundation (EFF) onlangs STARTTLS Everywhere. Daarbij leveren zij een plugin voor certbot waarmee ook een certificaat voor Postfix geïnstalleerd en onderhouden kan worden. Vergelijkbare plugins voor Dovecot en Sendmail zijn nog in de maak.
Daarnaast houden ze een lijst bij van domeinen die STARTTLS in combinatie met een CA-certificaat aanbieden, enigszins vergelijkbaar met STS maar dan gecentraliseerd. Bovendien kun je op hun portal je mail-domeinen checken op het gebruik van STARTTLS. Een vergelijkbare test is overigens ook beschikbaar op de Internet.nl portal.