SMTP umumnya memulai koneksi dalam plaintext lalu meningkatkannya dengan STARTTLS. Opportunistic TLS meningkatkan kerahasiaan ketika kedua sisi mendukungnya, tetapi upgrade tanpa autentikasi dapat ditekan atau dialihkan oleh penyerang aktif di jaringan. DANE untuk SMTP, yang ditetapkan dalam RFC 7672, menambahkan jalur autentikasi yang berakar pada DNSSEC.
MTA pengirim tidak menganggap setiap respons TLSA sebagai otoritatif. Pengirim terlebih dahulu memerlukan hasil DNSSEC-secure untuk data tujuan yang mengarahkan pengiriman. Ketika record TLSA yang dapat digunakan diperoleh secara aman untuk host MX terpilih, record tersebut membatasi kredensial server TLS yang dapat diterima pengirim.
Record TLSA melekat pada layanan SMTP
Record TLSA mengasosiasikan material sertifikat dengan endpoint transport tertentu. Untuk pengiriman SMTP ke host MX bernama mx.example.net pada TCP port 25, nama lookup berbentuk:
_25._tcp.mx.example.netRecord tersebut memiliki empat field: certificate usage, selector, matching type, dan certificate association data. RFC 6698 menetapkan selector untuk sertifikat penuh dan SubjectPublicKeyInfo, serta mode pencocokan untuk data eksak, SHA-256, dan SHA-512.
Bentuk DANE-EE yang umum dipakai dapat direpresentasikan sebagai:
_25._tcp.mx.example.net. IN TLSA 3 1 1 <sha256-of-spki>Di sini, usage 3 adalah DANE-EE, selector 1 memilih SubjectPublicKeyInfo, dan matching type 1 membandingkan digest SHA-256 miliknya. Digest tersebut bukan fingerprint sertifikat dalam arti umum; input digest ditentukan oleh selector.
DNSSEC menyediakan akar autentikasi
Record TLSA hanya membawa semantik keamanan DANE ketika data DNS-nya divalidasi melalui DNSSEC. Pengirim yang menerima data DNS insecure tidak dapat menaikkan data tersebut menjadi persyaratan TLS terautentikasi hanya karena sebuah RR TLSA muncul dalam respons.
Ketergantungan ini melampaui query TLSA terakhir. Routing SMTP dimulai dengan resolusi MX, sementara alias atau jalur delegasi dapat memengaruhi nama yang dipakai untuk lookup berikutnya. RFC 7672 menetapkan aturan pemrosesan agar pengirim dapat membedakan data routing terautentikasi dari data yang tidak dapat menopang autentikasi DANE.
Model trust yang dihasilkan berbeda dari validasi public CA biasa. Dengan usage DANE-EE, asosiasi TLSA yang diautentikasi DNSSEC dapat langsung mengautentikasi sertifikat end-entity atau public key server. Operator DNS menyatakan asosiasi kredensial bagi endpoint layanan tersebut melalui rantai DNSSEC.
DANE-EE dapat mengautentikasi tanpa validasi PKIX public CA
RFC 7672 merekomendasikan usage DANE-EE 3 dengan selector 1 dan pencocokan SHA-256 untuk deployment SMTP DANE. Dalam mode ini, pengirim mencocokkan kredensial leaf server TLS dengan asosiasi TLSA.
Untuk DANE-EE, sertifikat tidak harus membentuk chain ke public CA yang diterima pengirim. Nama sertifikat juga bukan sumber binding identitas server dalam mode ini. Record TLSA terautentikasi menyediakan binding tersebut untuk layanan SMTP.
Model ini memungkinkan operasi yang tidak bergantung pada himpunan trust Web PKI publik yang luas. Namun, pekerjaan lifecycle sertifikat tetap ada: operator masih perlu mengoordinasikan publikasi TLSA, TTL DNS, validitas DNSSEC, private key, dan rotasi kredensial server.
Asosiasi TLSA secure mengubah penanganan kegagalan
Tanpa policy terautentikasi, opportunistic SMTP TLS dapat melakukan fallback ketika TLS tidak tersedia. Perilaku itu mengutamakan pengiriman email, tetapi membuka kemungkinan downgrade di hadapan penyerang aktif.
Dengan record TLSA terautentikasi DNSSEC yang berlaku, pengirim memiliki informasi terautentikasi mengenai kredensial TLS yang diharapkan. Kegagalan menegosiasikan TLS yang dapat diterima atau kegagalan mencocokkan kredensial server karena itu tidak setara dengan ketiadaan opportunistic TLS biasa. Pengiriman ditunda, bukan diteruskan diam-diam melalui kanal plaintext tanpa autentikasi.
Perbedaan ini merupakan properti keamanan utamanya. DANE tidak sekadar meminta enkripsi; DANE memberi pengirim data terautentikasi yang dapat dipakai untuk memeriksa sesi TLS.
Beberapa record TLSA mendukung transisi kredensial
Satu RRset TLSA dapat memuat lebih dari satu asosiasi. Saat rotasi kredensial terencana, operator dapat memublikasikan asosiasi bagi kredensial saat ini dan penggantinya sebelum mengganti kredensial pada server.
Urutan aman bergantung pada caching DNS. Asosiasi pengganti perlu memiliki waktu untuk mencapai cache yang relevan sebelum server hanya menyajikan kredensial baru. Setelah RRset lama di cache kedaluwarsa dan transisi selesai, asosiasi lama dapat dihapus.
Publikasi beberapa record tidak berarti semuanya harus cocok. Pengirim dapat menerima sesi TLS ketika satu asosiasi terautentikasi yang berlaku cocok sesuai aturan protokol. Masa overlap ini memberi operator jalur untuk merotasi key atau sertifikat tanpa menciptakan celah autentikasi yang dapat dihindari.
DANE dan MTA-STS melindungi SMTP melalui control plane berbeda
DANE dan MTA-STS sama-sama dapat membuat SMTP TLS tahan terhadap downgrade, tetapi mekanisme trust dan publikasinya berbeda. DANE menempatkan asosiasi kredensial layanan terautentikasi di DNS dan bergantung pada DNSSEC. MTA-STS memublikasikan policy yang diambil melalui HTTPS dan memakai Web PKI untuk kanal policy tersebut.
DANE dapat mengikat penerimaan langsung ke material sertifikat atau public key melalui TLSA. MTA-STS menetapkan pola MX yang dapat diterima dan mewajibkan validasi sertifikat berdasarkan model policy-nya. Keduanya tidak tepat diperlakukan sebagai representasi yang saling menggantikan secara langsung.
TLS-RPT juga terpisah. Mekanisme itu menyediakan laporan agregat mengenai hasil pengiriman TLS; TLS-RPT tidak mengautentikasi record TLSA, sertifikat, atau koneksi SMTP.
Operasi DNSSEC dan kredensial menjadi satu batas deployment
DANE untuk SMTP menyatukan dua sistem operasional yang sering dikelola terpisah: DNSSEC dan TLS server email. Sertifikat server yang valid tidak cukup jika asosiasi TLSA yang dipublikasikan menunjuk ke material lain, sedangkan record TLSA yang benar tidak dapat menggantikan validasi DNSSEC yang rusak pada jalur yang menetapkan autentisitasnya.
Keterkaitan tersebut memang disengaja. Pengirim menerima kredensial TLS karena data layanan yang diautentikasi DNSSEC mengotorisasinya. Ketika rantai, record, dan kredensial yang disajikan tetap konsisten, SMTP memperoleh TLS terautentikasi tanpa hanya bergantung pada enkripsi oportunistik atau model trust public CA.