DANE En MTA-STS beide laten ondersteunende verzendende systemen geauthenticeerd SMTP transport afdwingen. Hun vertrouwensafhankelijkheden verschillen, en die verschillen zijn van belang vóór het eerste bericht, tijdens DNS problemen en wanneer certificaten veranderen. Om daartussen te kiezen, is een inventarisatie nodig van wat de ontvangende operator en zijn providers kunnen bijhouden, en niet alleen een succesvolle TLS handshake.
Volg één ontvangstroute
Referenties: RFC 7672 §2, RFC 8461 §3, RFC 8461 §4.
Gebruik example.com met MX mx1.example.net op TCP-poort 25. Onder SMTP DANE heeft de afzender de juiste DNSSEC-gevalideerde routing en TLSA ontdekkingsproces. Voor deze eenvoudige, niet-aliased host is de TLSA-eigenaar _25._tcp.mx1.example.net . Een bruikbare, veilige TLSA-koppeling vertelt een ondersteunende afzender hoe de TLS service moet worden geverifieerd. A TXT record op het ontvangende domein is geen vervanging. RFC 7672 secties 2 en 3.
Onder MTA-STS publiceert het ontvangende domein de ontdekking op _mta-sts.example.com en voert het zijn beleid uit via geverifieerde HTTPS op mta-sts.example.com . Het beleid autoriseert de beoogde MX namen en levert modus en levensduur. Voor STS-authenticatie moet de SMTP server voldoen aan de toepasselijke certificaatcontroles voor de openbare-sleutelinfrastructuur, inclusief een overeenkomend SAN DNS-ID onder RFC 8461 §4.2. Generieke TLS hostnaamtests alleen brengen niet het volledige profiel tot stand. Het policy-hostcertificaat en het mailservercertificaat beschermen verschillende services. RFC 8461 secties 3 en 4.
Vergelijk eerste contact- en faalstatussen
Referenties: RFC 7672 §2.1, RFC 8461 §2, RFC 8461 §3.3, RFC 8461 §10.2.
DANE kan zijn beleidsontdekking authenticeren via DNSSEC bij het eerste contact wanneer de validatieketen veilig is en er bruikbare gegevens bestaan. Dit is niet hetzelfde als het vertrouwen van elk antwoord dat door een recursieve oplosser wordt geretourneerd. Een vals validatieresultaat is niet gelijk aan een geldige, onveilige delegatie. Leg de vertrouwensrelatie van de oplosser en de validatiestatus van elk relevant antwoord vast.
MTA-STS heeft een bootstrap-beperking: een afzender zonder een bruikbaar cachebeleid kan worden verhinderd er een te verkrijgen. Een afzender die over een niet-verlopen handhavingsbeleid beschikt, moet dit blijven toepassen wanneer er geen nieuw beleid kan worden verkregen. Vergelijk daarom lege cache- en warme cache-gevallen afzonderlijk. Succesvolle HTTPS op één monitoringhost bewijst niet dat elke afzender het beleid heeft geleerd.
Beschouw vier expliciet hypothetische toestanden. Met veilig bruikbare DANE detectie bij het eerste contact kan een ondersteunende afzender de service authenticeren, zelfs als MTA-STS -acquisitie wordt onderdrukt. Als een niet-verlopen MTA-STS -beleid in de cache is opgeslagen, wordt dat beleid niet gewist als het mislukte ophalen plaatsvindt. Een sleutelwijziging van A naar B kan een oude TLSA-koppeling mislukken, zelfs als het nieuwe certificaat voldoet aan PKIX; overlap kan beide toetsen bedekken. Als u overschakelt naar een MX die is uitgesloten door een toepasselijk in de cache opgeslagen STS-beleid, kan de MX controle mislukken totdat een compatibel beleid is geleerd. Dit zijn op standaarden gebaseerde voorbeelden, niet-geobserveerde DNSSEC , cache- of leveringstests.
De mechanismen zijn niet universeel gecombineerd en vereisen in de regel dat beide slagen. RFC 8461 §2 stelt een specifieke niet-interferentievereiste vast: Succesvolle MTA-STS validatie MOET de falende DANE validatie NIET opheffen. Een generiek vergelijkingsmodel dat erop aandringt dat beide moeten slagen, is geen normatief zenderalgoritme.
Plan twee keer dezelfde rollover
Referenties: RFC 7672 §4, RFC 8461 §8.
DANE-EE-gebruik 3 authenticeert via de beveiligde associatie: RFC 7672 §3.1.1 vereist niet de PKIX-identiteits- of certificaatvervalcontroles die door STS worden gebruikt. Pas deze uitzondering niet klakkeloos toe op elk TLSA-gebruik. Voor DANE-EE met keuzeschakelaar SPKI en SHA-256, het wijzigen van de openbare sleutel verandert de associatiesamenvatting. Publiceer de oude en nieuwe associaties voordat u de nieuwe sleutel implementeert, laat oude DNS caches en gerelateerde handtekeningrecords verouderen en behoud dekking voor elk actief eindpunt. Het opnieuw uitgeven van een certificaat met dezelfde sleutel verschilt van het roteren van de sleutel. RFC 7672 sectie 4.
Voor MTA-STS vereist een gewone certificaatvernieuwing waarbij de geldige MX identiteit en het vertrouwen behouden blijven, op zichzelf geen veranderende beleids- MX patronen. Een MX migratie doet dat wel: stel een beleid op dat zowel oude als nieuwe ontvangende hosts bestrijkt en houd rekening met afzenders die het eerdere beleid behouden. Geen van beide modellen staat het negeren van een onderbroken route toe alleen maar omdat een andere schijf groen meldt.
Bepaal op basis van operationeel eigendom
Referenties: RFC 8461 §2.
Maak een lijst van de teams die DNS van de ontvanger, MX-host DNS , DNSSEC ondertekening, SMTP certificaatimplementatie en HTTPS-beleidhosting controleren. Een gehoste provider kan een afhankelijkheid beheren die de domeineigenaar niet rechtstreeks kan wijzigen. Zorg voor een ondersteund proces voordat u controle aan klanten belooft. Wanneer beide mechanismen worden ingezet, mag een succesvolle MTA-STS validatie de falende DANE validatie niet overschrijven. Voor deze handleiding is geen live DNSSEC keten of SMTP levering uitgevoerd; de vergelijking is gebaseerd op standaarden en de lokale voorbeelden zijn expliciet synthetisch.