TLS biasanya mengautentikasi server melalui rantai sertifikat yang berakhir pada trust anchor yang sudah diterima klien. DANE menambahkan jalur lain: domain dapat menerbitkan record TLSA di DNS dan melindunginya dengan DNSSEC. Klien yang mendukung DANE kemudian dapat mencocokkan material sertifikat dari TLS handshake dengan asosiasi yang diterbitkan domain.
RFC 6698 mendefinisikan resource record TLSA. RFC 7671 memperbarui aturan operasional dan mempersempit beberapa pilihan deployment. Properti keamanannya spesifik: hanya data TLSA yang tervalidasi DNSSEC yang layak digunakan untuk autentikasi DANE. RRset TLSA berstatus insecure atau indeterminate tidak menyediakan binding DNS terautentikasi yang dibutuhkan DANE.
Nama query menunjuk endpoint transport
Untuk layanan TLS langsung, owner name TLSA menggabungkan port layanan, protokol transport, dan nama server. Layanan TLS pada TCP port 443 di www.example.com memakai bentuk berikut:
_443._tcp.www.example.com. IN TLSA ...Label di bagian depan memiliki fungsi keamanan. Asosiasi dibatasi ke endpoint transport tertentu, bukan menjadi pernyataan sertifikat tanpa batas untuk setiap layanan di bawah nama host tersebut.
Protokol yang menemukan server melalui record seperti SRV memerlukan aturan konstruksi khusus protokol. RFC 7673, misalnya, membentuk query TLSA dari port SRV, transport, dan host target. Klien tidak dapat mengganti host atau port secara sembarang lalu menganggap asosiasi yang dihasilkan memiliki cakupan yang sama.
Empat field membentuk asosiasi sertifikat
Record TLSA berisi tiga parameter numerik diikuti Certificate Association Data:
usage selector matching-type association-dataField certificate usage menentukan peran asosiasi. RFC 7671 memberi nama empat nilai standar: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), dan DANE-EE(3).
Selector menentukan material sertifikat yang dicocokkan. Cert(0) memilih sertifikat lengkap, sedangkan SPKI(1) memilih SubjectPublicKeyInfo. Pemilihan SPKI dapat mempertahankan asosiasi saat sertifikat diperbarui selama kunci publik yang sama tetap digunakan.
Matching type menentukan representasi yang disimpan di DNS. Full(0) membawa material terpilih secara langsung. SHA2-256(1) dan SHA2-512(2) membawa digest. RFC 7671 merekomendasikan asosiasi berbasis digest dibanding record sertifikat lengkap yang besar, salah satunya karena respons DNS berukuran besar kurang sesuai untuk pengiriman UDP yang andal.
Asosiasi ringkas dapat berbentuk:
_443._tcp.www.example.com. IN TLSA 3 1 1 <sha256-of-spki>Pada contoh ini, 3 1 1 berarti DANE-EE, SPKI, dan SHA-256. Field terakhir berisi digest SHA-256 dari SubjectPublicKeyInfo yang dipilih.
DANE-EE dapat mengautentikasi kunci endpoint secara langsung
Pada DANE-EE(3), asosiasi TLSA berlaku pada material end-entity yang disajikan server. RFC 7671 menetapkan bahwa binding kunci publik server ke nama layanan bertumpu pada RRset TLSA untuk usage ini. Klien memeriksa apakah material leaf yang disajikan cocok dengan asosiasi TLSA yang dapat digunakan.
Mekanisme ini berbeda secara material dari validasi PKIX biasa. Untuk DANE-EE, record TLSA sendiri menyediakan asosiasi terautentikasi, sehingga trust anchor CA publik yang sudah dikonfigurasi tidak diperlukan untuk jalur autentikasi DANE tersebut. RFC 7671 juga menetapkan bahwa pencocokan nama sertifikat dan penegakan masa berlaku untuk DANE-EE mengikuti aturan asosiasi TLSA, bukan pemeriksaan PKIX biasa.
TLS handshake tetap diperlukan. Server masih harus membuktikan kepemilikan private key yang berpasangan dengan public key terautentikasi sesuai mekanisme autentikasi TLS yang dinegosiasikan. TLSA menerbitkan asosiasi; TLSA tidak menerbitkan atau menggantikan private key.
DANE-TA mendelegasikan trust ke material certificate authority
DANE-TA(2) memakai pendekatan berbeda. Alih-alih mengasosiasikan layanan langsung dengan leaf certificate atau key, usage ini menunjuk material trust anchor yang digunakan untuk memvalidasi rantai sertifikat server.
Model ini dapat mendukung trust anchor privat atau nonpublik tanpa mengharuskan anchor tersebut dipasang lebih dahulu pada setiap klien. Detail operasional tetap penting. RFC 7671 merekomendasikan Cert(0) bagi penerbit DANE-TA agar constraint sertifikat tetap menjadi bagian dari material trust anchor yang dipilih. RFC tersebut juga mensyaratkan material sertifikat yang sesuai tersedia dalam rantai server ketika asosiasi DANE-TA berbasis digest akan membuat klien tidak memiliki sertifikat yang diperlukan untuk membangun dan memverifikasi path.
Perbedaan DANE-EE dan DANE-TA bersifat arsitektural. DANE-EE mengasosiasikan material endpoint secara langsung; DANE-TA mengasosiasikan otoritas yang dipakai dalam validasi rantai sertifikat.
Usage PKIX menambahkan constraint DNS tanpa membuang PKIX
PKIX-TA(0) dan PKIX-EE(1) tetap mempertahankan validasi PKIX. Asosiasi TLSA membatasi material sertifikat yang juga harus lolos pemeriksaan PKIX yang berlaku. Persyaratan seperti CA trust yang diterima, pemeriksaan identitas, dan validasi PKIX lain tetap relevan.
RFC 7671 merekomendasikan agar desain aplikasi pada umumnya tidak mendukung keempat usage tanpa seleksi. Spesifikasi protokol dapat memilih usage yang sesuai dengan model autentikasinya. Karena itu, deployment harus mengikuti aturan protokol aplikasi yang memakai DANE, bukan sekadar menerbitkan record TLSA yang valid secara sintaksis dan menganggap setiap klien DANE akan memperlakukannya secara identik.
DNSSEC menjadi bagian dari jalur autentikasi
Record TLSA yang diambil dari DNS biasa tanpa tanda tangan tidak cukup. DANE bergantung pada rantai validasi DNSSEC yang menetapkan RRset TLSA sebagai secure. Jika klien menyerahkan validasi kepada resolver, jalur antara klien dan validating resolver tersebut juga harus menjaga asumsi keamanan yang dibutuhkan implementasi DANE.
Konsekuensinya masuk ke ranah operasional. Rollover sertifikat atau kunci harus dikoordinasikan dengan publikasi DNS, TTL DNS, tanda tangan DNSSEC, serta material yang benar-benar disajikan endpoint TLS. RFC 7671 menjelaskan urutan rollover saat asosiasi lama dan baru hadir bersamaan sebelum endpoint berubah. Menerbitkan hanya material masa depan terlalu cepat, atau menghapus material aktif terlalu cepat, dapat menghasilkan RRset TLSA secure yang tidak cocok dengan server aktif.
Sifat fail-closed yang sama berlaku ketika data TLSA secure tersedia tetapi autentikasi gagal. Untuk protokol yang mewajibkan authenticated DANE TLS, mismatch bukan petunjuk untuk mengabaikan record lalu melanjutkan seolah record tersebut tidak ada. Standar khusus aplikasi menentukan kebijakan koneksi secara tepat, terutama untuk opportunistic TLS.
Batas keamanan mencakup operasi DNS dan TLS
DANE tidak menggantikan DNSSEC, TLS, kontrol siklus hidup sertifikat, atau perlindungan private key. DANE menyatukan komponen tersebut. DNSSEC mengautentikasi asosiasi yang diterbitkan; TLS menyediakan material peer aktif beserta proof of possession; aplikasi menentukan kapan autentikasi DANE wajib dan usage TLSA mana yang diterima.
Komposisi tersebut membentuk batas operasional yang tegas. Sertifikat TLS yang benar tetapi tidak disertai state TLSA secure yang cocok dapat gagal. RRset TLSA yang benar tetapi menunjuk material yang tidak disajikan endpoint juga dapat gagal. Record TLSA yang cocok tetapi diterima tanpa status keamanan DNSSEC yang dipersyaratkan tidak membawa otoritas autentikasi DANE.
Bagi operator, unit operasionalnya bukan sertifikat semata. State yang harus sinkron mencakup RRset TLSA bertanda tangan DNSSEC, endpoint TLS, dan kebijakan klien yang menafsirkan keduanya.