| 作者：中華電信 林方傑工程師 |
DANE是為了緩解什麼問題？
關於DANE（DNS-based Authentication of Named Entities）問世的理由，筆者認為必須從「在網路上安全傳輸」的需求講起。資訊安全至少有CIA三個面向[1]，我們先關注其中的「Confidentiality」。如何避免所傳送的資料遭竊取？「加密傳輸」是理所當然的對策。而加密傳輸最直覺的做法，是由連線兩端約定好加解密的關鍵（如對稱式加密金鑰），只要協議夠複雜且未被外界得知，則資料的隱密性在傳輸過程中應可得到一定程度的保障。
但有個衍生的（類似雞生蛋、蛋生雞的）問題是，在尚未完成加密傳輸協議的情況下，連線兩端如何確保加解密關鍵不被第三方得知呢？這時「非對稱加密演算法」的「以公鑰加密只有對應之私鑰可解密」之特性便能派上用場。由於私鑰只應由金鑰製造者持有，選用對應公鑰來加密訊息便確保了只有私鑰製造/持有者可解密[2]。
然而，這又會衍生另一個問題，若誤將駭客的公鑰當作原連線對象所提供，或者連線對象根本是冒名頂替的，則資料仍可能被揭露給非預期的對象。那麼如何確保公鑰與對象正確呢？找第三方掛保證是有幫助的選項。現行「公開金鑰基礎建設」（Public Key Infrastructure，簡稱PKI）[3]機制中，有「憑證頒發機構」（Certificate Authority，CA）當掛保證的第三方，負責將公鑰與公鑰來源方的識別等資訊製成「數位憑證」（digital certificates）供查驗。由於數位憑證是基於「數位簽章」（digital signature）[4]技術，可保障資料的「完整性」（Integrity）與「不可否認性」（Non-Reputation）。在網路世界中，被連線的伺服器便可靠這樣的憑證（實務所需的格式與內容如RFC 5280「X.509」所定義），對外做出「自己是域名的合法代表、是正確公鑰的提供者」等有力聲明[5]。
但，CA總是可信嗎？撇開惡意CA或作業疏失導致錯發（mis-issue）憑證，現行「PKIX」（Public-Key Infrastructure for X.509 certificates）機制中，任何CA可為任何域名簽發憑證[6]。這種自由度的風險在於，若一家規模較小的CA遭駭並胡亂為知名公司或服務的域名簽發了憑證，這將給予駭客絕佳的攻擊機會。舉個例子[7]，假設Jason架了個網站，並以域名a-example-domain.com搭配CA1簽發的憑證對外提供服務。而駭客可從比較沒那麼有名、審查不是那麼嚴格的CA2也為a-example-domain.com取得另一張憑證，置於假造的站臺主機。如果再搭配快取污染（cache poisoning）等手段誤導終端客戶連上駭客的假站臺，由於CA2的憑證也有效，瀏覽器網址欄同樣有個精美的鎖頭，一般用戶不容易察覺有異。實際案例可參閱2011年DigiNotar遭駭等事件報導[8]。
有哪些對策、如何緩解？
因應上述的問題，「憑證透明」（Certificate Transparency，CT）、「HTTP公鑰固定」（HTTP Public Key Pinning，HPKP）等安全機制被提出。前者（CT）要求CA將所簽發憑證都登錄到可供查驗的日誌，但一般認為資訊透明主要補強憑證誤發後偵測與追查，事前的防範則幫助有限[9]；後者（HPKP）原理是在HTTP header中指定CA、讓使用者第一次連線取得並記下供後續驗證，但這方法因缺乏彈性已式微[10]。
DANE也能用來保護域名免受錯發或濫發憑證的糾纏（是的，主角終於登場）。考量網路連線乃至憑證的簽發本來都與域名息息相關，加上有DNSSEC（Domain Name System Security Extension）這個安全協定可確保DNS所傳遞資料的完整性（data integrity）、來源可驗證性（origin authentication of DNS data），以及可驗證之不存在性（authenticated denial of existence）[11]，DNS應該是個不錯的傳遞憑證相關資訊之管道。而DNS紀錄的公開性（任何人都可透過DNS查詢取得）[12]更可讓客戶端直接自域名維運者（DNS operator）取得第一手且可信的「憑證聲明」[13]，做為後續查驗憑證的指引或依據。
那麼，DANE（的憑證聲明）可以如何派上用場呢？承前例，如果Jason為a-example-domain.com設定A或AAAA紀錄、定義站臺伺服器IP位址的同時，也透過DNS紀錄對外聲明：「我這域名只該搭配CA1所簽發的憑證」，則當終端客戶被誤導向CA2的假站臺時，就可索取並對照上述Jason關於憑證的聲明，從而獲得發現異常的機會。反過來說，對於CA1（或任何被青睞且被聲明的CA）來說，也可在將a-example-domain.com的憑證簽發給聲稱是Jason的人之前，先透過DNS查詢、參考DNS紀錄所承載的聲明，來確認Jason是否真的有要索取一份本CA的憑證[14]。
而除了如上述規範可簽發憑證的CA，限制可用的憑證是哪幾張，甚至直接指定「信任錨點」（trust anchor）[15]都屬於DANE的使用案例（use case）。依照RFC 6394，憑證聲明可分為「CA Constraints」、「Service Certificate Constraints」、「Trust Anchor Assertion and Domain-Issued Certificates」 如下表所列：
| CA Constraints | 客戶端只應該接受指定CA所簽發的憑證 |
| Service Certificate Constraints | 客戶端只應該接受特定的憑證 |
| Trust Anchor Assertion and Domain-Issued Certificates | 客戶端只應該接受「域名提供」之信任錨點與憑證 |
表･DANE的憑證聲明
其中，「CA Constraints」與「Service Certificate Constraints」由於規範的是憑證或信任錨點，使DANE可做為現行PKIX的輔助，而不只是替代方案。相對的，「Trust Anchor Assertion and Domain-Issued Certificates」則補強了自簽或系出「無」名門憑證的缺陷，如終端客戶、瀏覽器、乃至OS通常不會有這些憑證的信任錨點（以判斷憑證簽發單位的真偽）。在現行PKIX機制下，面對瀏覽器「此網站的安全性憑證有問題」的提醒，終端客戶也只能接受憑證並承擔風險；但在DANE的運作下，終端客戶可基於DNS(SEC)提供的可靠聲明資訊（做為對照組），對所得之憑證有更大的信心。
實作面上，一種新的DNS紀錄類型「傳輸層安全性驗證（Transport Layer Security Authentication，TLSA）」被提出，每一筆TLSA紀錄都有「Usage」、「Selector/Matching」、「Certificate for Association」之欄位，如下表所列：
| Usage | 選用哪一種憑證聲明（選項如上表所列三項） |
| Selector/Matching | TLS憑證應該如何比對，例如：完整比對，或者只比對雜湊值（hash digest） |
| Certificate for Association | 實際要被比對的資料 |
表･TLSA紀錄的欄位
關於各欄位的值域各位讀者可參閱RFC 6698，這裡先不詳述，而再承前例情境示範TLSA紀錄設定的方向：為了聲明終端客戶（針對此服務）只該接受CA1所簽發的憑證，Jason可為a-example-domain.com的https服務提供一筆「_443._tcp.a-example-domain.com」的TLSA紀錄定義如下：
| Usage | 選擇代表「CA constraint」的值 |
| Selector/Matching | 提示待比對資料是如何取得（即如何被驗算），如SHA-1 digest |
| Certificate for Association | CA1本身憑證的雜湊值 |
表･TLSA紀錄的應用
（筆者翻譯[註6]）
綜觀來說，DNS解析與DNSSEC是DANE運作的基石。DNS解析的公開性（指任何人都可查詢）可提高資訊透明度並有助於檢核[17]。DNSSEC應用的數位簽章技術可為DANE基於DNS解析傳遞憑證聲明等資訊的管道增加可信度。而基於域名階層所建構的DNSSEC「信任鏈」（Chain of Trust）也使信任錨點數大為收斂（僅剩DNS root根域名）。相對的，web PKI中每家CA都對應一個信任錨點、且有「任何一家CA可簽發任何域名的憑證」及「不同CA可為同一個域名簽發各自版本的憑證」等備受爭議的自由度[18]，使得資安防護在web PKI機制中因可攻擊的點多（每個信任錨點都可能是破口）而更具挑戰性。
DANE的現況與前景
前面都在說DANE的好話，接下來討論些待克服的挑戰與潛在問題，以平衡報導。
首先是DNS相關議題：除了（伺服端）為域名進行DNSSEC簽署的比率待提升，DNS解析的耗時（且DNSSEC牽涉額外、專用DNS紀錄的查詢）[19]、「DNS維運者」隨DANE的發展而在網路資訊安全領域中的戲分越發吃重、會否增加單點失效的風險都需要各界集思廣益。而最關鍵的，客戶端的應用程式會否支援新DNS紀錄的查詢及結果的判讀，目前看來在web領域（即瀏覽器）的接受度與配合度不太樂觀……（據說這與「CAA紀錄」被發展相關，但是另一段故事了）[20]。
有趣的是，相對於在web領域的窒礙難行，mail領域對DANE的態度就顯得親切得多。比如微軟就宣布其Windows Server、Office 365等產品或服務支援DANE[21]，關於DANE如何為SMTP帶來幫助，則可參閱相關討論[22]。
[1] 關於CIA https://www.forcepoint.com/zh-hant/cyber-edu/cia-triad。
[2] 關於 HTTPS 原理、對稱式加密、非對稱式加密可參閱 https://medium.com/@RiverChan/基礎密碼學-對稱式與非對稱式加密技術-de25fd5fa537、https://www.youtube.com/watch?v=w0QbnxKRD0w 等解說。
[3] 關於 PKI 可參閱 https://zh.wikipedia.org/wiki/公開金鑰基礎建設 等說明。
[4] 關於數位簽章可參閱 https://medium.com/@yellowgirl3614/密碼學-三-數位簽章-f8c6a78da46b 等專文。
[5] 關於數位憑證筆者參閱了 https://medium.com/schaoss-blog/前端三十-28-web-http-和-https-的差別是什麼-21ccafb6f36f、https://www.ssl.com/faqs/what-is-an-x-509-certificate/ 等介紹。
[6] IETF Journal《DANE: Taking TLS Authentication to the Next Level Using DNSSEC》https://www.ietfjournal.org/dane-taking-tls-authentication-to-the-next-level-using-dnssec/
[7] 引用自 https://docs.microsoft.com/zh-tw/windows-server/networking/dns/what-s-new-in-dns-server。
[8] 關於CA遭駭可參閱《Inside ‘Operation Black Tulip’: DigiNotar hack analysed • The Register》https://www.theregister.com/2011/09/06/diginotar_audit_damning_fail/、《Comodo SSL Affiliate | The Recent RA Compromise》https://blog.comodo.com/other/the-recent-ra-compromise/。
[9] 關於 CT 的討論筆者參閱 https://blog.apnic.net/2019/07/05/whither-dane/、https://certificate.transparency.dev/。
[10] 關於 HPKP 的議題筆者參閱 https://zh.wikipedia.org/wiki/HTTP公鑰固定、 https://blog.gslin.org/archives/2016/09/14/6842/hpkp-遇到的阻礙/。
[11] DNSSEC的優點引用自《DNSSEC安全技術簡介》http://www.cc.ntu.edu.tw/chinese/epaper/0022/20120920_2206.html 。
[12] 關於DNS紀錄為公開資料可參閱筆者拙作《重新認識DoT/DoH、DNSSEC的定位與原理》https://blog.twnic.tw/2020/02/27/6205/ 。
[13] 引用同註6，其中「DNS/domain operator」雖然不見得等同於「domain holder」或service owner，但前者一定經後者授權才能扮演此角色。
[14] RFC 6394《Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)》https://datatracker.ietf.org/doc/rfc6394/ 、https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf。
[15] 關於 trust anchor、chain of trust 的觀念筆者參閱 https://medium.com/@clu1022/那些關於ssl-tls的二三事-十二-chain-of-trust-f00da1f2cc15、https://csrc.nist.gov/glossary/term/trust_anchor。
[16] RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》https://www.ietf.org/rfc/rfc6698.txt
[17] https://www.farsightsecurity.com/blog/txt-record/caa-records-farsight-20170825/
[18] RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》https://www.ietf.org/rfc/rfc6698.txt
[19] 引用自 https://blog.apnic.net/2019/05/27/dns-oarc-30-bad-news-for-dane/ 的 ”extended time taken to perform DNSSEC validation…”
[20] 關於DNS、DNSSEC應用在DANE的意義，DANE所遭遇的反對引用自 https://blog.apnic.net/2019/07/05/whither-dane/。
[21] https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494、https://www.theregister.com/2020/04/07/microsoft_dane_office/
[22] https://blog.apnic.net/2019/11/20/better-mail-security-with-dane-for-smtp/
