DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC
TLS biasanya mengautentikasi server melalui aturan validasi sertifikat yang ditetapkan aplikasi dan trust model-nya. DANE menambahkan binding berbasis DNS: resource record TLSA mengasosiasikan endpoint layanan dengan material sertifikat atau public key, sedangkan DNSSEC menyediakan data DNS terautentikasi untuk asosiasi tersebut.
Batasnya tegas. RRset TLSA yang berstatus insecure atau memiliki status DNSSEC indeterminate tidak dapat menjadi asosiasi DANE terautentikasi. Karena itu, DANE bergantung pada validasi DNSSEC dan tidak menganggap transport DNS biasa sebagai bukti yang memadai.
Nama TLSA mengidentifikasi endpoint layanan
Lookup TLSA dicakup oleh port, transport, dan hostname. Untuk layanan TLS pada TCP port 443 di www.example.org, owner name berbentuk:
_443._tcp.www.example.org.Skema penamaan tersebut memisahkan layanan yang berbagi host tetapi memakai port atau transport berbeda. Asosiasi TLSA untuk satu endpoint bukan pernyataan umum bagi setiap layanan TLS pada host yang sama.
Data RR memiliki empat bagian: certificate usage, selector, matching type, dan certificate association data.
_443._tcp.www.example.org. IN TLSA 3 1 1 <sha256-digest>Tiga parameter numerik menentukan objek yang diasosiasikan dan cara field terakhir dibandingkan.
Certificate usage menetapkan relasi trust
RFC 6698 menetapkan empat nilai certificate usage. Usage 0 membatasi CA dalam certification path yang valid menurut PKIX. Usage 1 membatasi sertifikat end-entity sambil mempertahankan validasi PKIX. Usage 2 menyediakan trust-anchor assertion untuk validasi path. Usage 3 secara langsung mengasosiasikan sertifikat end-entity atau material public key yang dipilih dan tidak mewajibkan validasi PKIX untuk asosiasi tersebut.
RFC 7671 memberikan nama simbolis PKIX-TA(0), PKIX-EE(1), DANE-TA(2), dan DANE-EE(3). Perbedaan ini penting karena digest yang cocok saja tidak menjelaskan semantik trust; field usage yang menentukannya.
Untuk desain khusus DANE, RFC 7671 merekomendasikan dukungan yang berpusat pada DANE-TA(2) dan DANE-EE(3), bukan memperlakukan keempat usage sebagai pilihan yang setara.
Selector memilih byte sertifikat atau material public key
Selector 0 berarti sertifikat lengkap yang dikodekan dalam DER. Selector 1 berarti struktur SubjectPublicKeyInfo yang dikodekan dalam DER.
Pilihan ini mengubah perilaku rotasi. Asosiasi atas sertifikat lengkap berubah ketika byte sertifikat berubah. Asosiasi atas SubjectPublicKeyInfo dapat tetap sama saat sertifikat diganti jika public key yang sama dipertahankan.
Stabilitas tersebut tidak otomatis lebih baik. Mempertahankan key yang sama dan beralih ke key baru merupakan keputusan operasional yang berbeda, dan RRset TLSA yang dipublikasikan harus tetap kompatibel dengan certificate chain atau key yang benar-benar disajikan server.
Matching type mengatur representasi perbandingan
Matching type 0 menyimpan data terpilih secara langsung. Matching type 1 menyimpan digest SHA-256, sedangkan matching type 2 menyimpan digest SHA-512.
Record 3 1 1 yang umum karena itu berarti:
3: DANE-EE1: memilihSubjectPublicKeyInfo1: membandingkan digest SHA-256
Digest tersebut merupakan certificate association data, bukan fingerprint sertifikat dengan semantik trust yang berdiri sendiri. Maknanya berasal dari tuple parameter TLSA lengkap dan RRset terautentikasi DNSSEC yang membawanya.
Rotasi key memerlukan overlap pada DNS dan state layanan
Deployment TLSA dapat gagal selama rotasi sertifikat atau key yang sebenarnya valid jika perubahan DNS dan perubahan server diurutkan dengan buruk. RFC 7671 menjelaskan RRset transisi yang memuat asosiasi kompatibel dengan state layanan saat ini dan state yang akan datang sebelum endpoint beralih key.
Operasi ini sensitif terhadap cache. Mempublikasikan asosiasi baru cukup awal agar data DNS lama kedaluwarsa mengurangi interval ketika validator dapat melihat RRset yang hanya cocok dengan state endpoint sebelumnya.
Setelah transisi layanan dan interval cache DNS yang relevan, asosiasi lama dapat dihapus. Urutan tepatnya bergantung pada usage, selector, certificate chain, rencana key, dan protokol aplikasi yang dipakai.
DANE tidak membuat setiap client TLS menjadi validator DNSSEC
Client dapat memvalidasi DNSSEC sendiri atau mengandalkan komponen validator lain, tetapi jalur antara client dan validator tersebut harus mempertahankan properti keamanan yang diperlukan desain DANE. Resolver non-validating tidak menghasilkan data TLSA terautentikasi hanya karena query DNS mencapainya melalui kanal yang terlindungi.
Dukungan aplikasi juga menentukan hasil. Publikasi record TLSA tidak memaksa software tanpa pemrosesan DANE untuk menegakkannya. Autentikasi DANE efektif hanya ketika protokol aplikasi dan client terkait menerapkan perilaku TLSA dan DNSSEC yang diperlukan.
Kontrol yang dihasilkan bersifat spesifik: data TLSA yang terautentikasi DNSSEC dapat mengikat endpoint layanan ke material sertifikat atau public key terpilih dengan semantik trust yang eksplisit. Reliabilitasnya bergantung pada validasi DNSSEC, parameter TLSA yang benar, state layanan yang kompatibel, dan rollover yang disiplin, bukan sekadar keberadaan sebuah record DNS.