Webサービスにおける安全な通信を実現するためにTLS（Transport Layer Security）プロトコル[1]では通信データの暗号化と通信相手の認証が行われている。本稿で取り上げるDANE（DNS-based Authentication of Named Entities）は、このTLSにおける通信相手の認証のために、認証局ではなくDNSを使う仕組みである。本稿では、2011年度上半期のインターネットにおけるセキュリティ技術の動向としてDANEを紹介する。
　DANEは、2010年8月頃、KIDNS（Keys in DNS）と呼ばれ、IETF（Internet Engineering Task Force）のメーリングリスト¹で議論が始まった仕組みで、2010年末にワーキンググループが設立され、プロトコルの策定に向けた議論が活発化した。DANEは、DNSを使って、電子証明書を配送したり電子証明書とサーバとの関連付けの正しさを確認したりできる仕組みで、電子証明書（以下、証明書と呼ぶ）を使ったサーバ認証のために使うことができる。DNSのゾーン管理者がこのリソースレコードを登録するため、原理的には、サーバのドメイン名の正しさを確認でき、認証局のような第三者証明機関を使う必要がない。
　電子証明書利用して通信相手の認証を行う点はこれまでのTLSの使われ方と変わらないが、電子証明書や鍵の確認のための信頼構造は、認証局を使った仕組みとDANEでは大きく異なる。DANEはまだ提案と議論が進められている段階ではあるが、認証の信頼構造という意味で大きな変化をもたらす可能性がある。本稿では背景や仕組みの概要を述べた上で、DANEがもたらす変化について考察する。

　DANEの議論が開始された背景には、DNSルートゾーンへのDNSSECの導入が挙げられる。DNSルートゾーンにDNSSECが導入されトラストアンカーのデータ（KSKのハッシュ値）がIANA²のWebページで公開されたのは2010年7月15日である[2]。このことで、IANAのトラストアンカーを利用することで、様々なドメイン名のDNSSECのリソースレコードの正しさを検証できるような基点ができたことになる。このDNSSECによるセキュアな情報伝達の仕組みを応用し、ドメイン名を識別子とする通信相手の認証手段として検討し始められたのがDANEである。2010年8月にメーリングリストKeyassure が設置された時に、現在のDANE WGのチェアであるWarren Kumai氏によって投稿されたProblem Statementにこの背景をうかがうことができる³。その後2010年12月にDANE WGが設立され、2011年7月現在は、このWGで以下の2つのドキュメントが議論されている。

　DANE WGの趣意書によると、2011年後半までに現在議論されているTLSおよびDTLSとIPsec向けの仕様が検討されることになっている[5]。

　DANEでは、ドメイン名にサーバ認証に使われる証明書や鍵の情報が関連づけられていることを示す”Certificate Association”が重要な役割を持っている。この関連づけは、DNSのゾーン管理者によってゾーンへのリソースレコードの登録を通じて行われ、特定のドメイン名への証明書などの関連づけが担保されることを意味している。この関連づけを担保するため、DANEではDNSSECを利用することが実質的に前提となっている⁴。
　関連づけできるものには、証明書のフィンガープリント、証明書自体、そして証明書に含まれる公開鍵があり、いずれもDNSサーバでTLSAと呼ばれるリソースレコード（以下、TLSAレコードと呼ぶ）に格納される。TLSAとはTLS Associationの略で、TLSにおけるCertificate Associationである。図1にTLSAレコードの例を示す。

(1) エンドエンティティ証明書のフィンガープリントのリソースレコード
   _443._tcp.www.example.com. IN TLSA (
      1 1 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98
          c735fcca79f09230aa7141 )


(2) 認証局証明書のリソースレコード
   _443._tcp.www.example.com. IN TLSA (
      2 0 308202c5308201ada00302010202090... )

　(1)はエンドエンティティ証明書のフィンガープリントのリソースレコードである。図1の例では、www.example.com というドメイン名のホストにTCPの443番ポートに接続するために使われるリソースレコードが示されている。「エンドエンティティ」と記述されているが、ここではTLSサーバを意味している。TLSAレコードのリソースデータは”5c150”で始まる文字列で、TLSサーバの証明書のハッシュ値（フィンガープリント）を示している。(1)の2行目の最初の「1」はエンドエンティティ、つまりサーバ証明書であることを示しており、次の「1」は証明書のSHA-256のハッシュ値が入っていることを示している。
　(2)は認証局証明書のリソースレコードである。(1)と同様にwww.example.comというドメイン名のホストにTCPの443番ポートで接続するために使われる。(2)の2行目の最初の「2」は認証局証明書であることを示しており、次の「0」は”30820”で始まるリソースデータが、証明書のハッシュ値ではなく証明書そのものであることを示している。
　TLSAリソースレコードとして登録できる値の種類とその使われ方は”Using Secure DNS to Associate Certificates with Domain Names For TLS”の”4. Semantics and Features of TLSA Certificate Types”に示されている[3]。

　DANEのTLSAを使ったサーバ証明書の検証、すなわちサーバ認証は次のようになると考えられる。はじめにhttpsでwww.example.comに接続しようとするTLSクライアントは、「_443._tcp.www.example.com」のTLSAをDNSで検索する。次にTLSでwww.example.comに接続しTLSのプロトコルを使ってサーバ証明書を受け取る。 (1)の場合には「www.example.com」のサーバ証明書のfingerprintとTLSAのリソースデータを比較し、一致している場合にサーバ証明書は有効であるとみなされる。つまりDNSでドメイン名に関連付けられた”Certificate Association”を使って、www.example.comと通信して得られたサーバ証明書の正しさを確認しているのである。
　(2)の場合には、「www.example.com」のサーバ証明書とTLSのプロトコルを使って得られた証明書などを用いて証明書検証を行うが、その証明書チェインの中に(2)のTLSAの認証局証明書と一致したものがあれば、サーバ証明書が有効であると判断される。ここでは認証局証明書を記述しているが、この認証局はDNSのゾーン管理者が立ち上げた認証局でよい。DNSを通じて適宜証明書を伝えることができるため、予めクライアント側に認証局証明書がインストールされている必要がない。
　DANEでは、ドメイン名の正しさを確認することを目的としたサーバ認証のために、第三者によって運用されている認証局が必要ないことがわかる。

　DANEはTLSのサーバ認証において、第三者としての認証局を必要としない仕組みである。このことについて2点考察したい。
　1点目は、TLSにおける信頼構造についてである。従来の認証局を用いたサーバ認証とDANEによるサーバ認証とでは、認証するプログラムに必要となる信頼の先が異なる。この違いを図2に示す。

図2：Domain Validation証明書とDANEの信頼構造の違い

　認証局によってドメイン名の正しさが確認され発行されたサーバ証明書はDomain Validation(DV)証明書と呼ばれる。DV証明書を使ったサーバ認証を行うためには、Webブラウザなどがサーバ認証を行う際、認証局を中心とした認証基盤に信頼をおくことになる。DANEの場合には、TLSサーバのドメイン名を登録しているゾーンの運用者がドメイン名とサーバ証明書との関連付けを行うため、ドメイン名の正しさを担保する構造がDNSに直結している。DNSでドメイン名とTLSAを正しく調べることができれば、正しいサーバであると見なされるのである。信頼構造としては、DNSルートゾーンが単一の信頼のポイントになると考えられる一方で、認証の対象となるTLSサーバが登録されたDNSゾーンに至るまでの一連のDNSSECの運用が正しく行われている必要があり、信頼性を担保する仕組みとしては構造が複雑になる可能性がある。
　2点目は、Extended Validation証明書（EV証明書）のようなサーバとドメイン名以外の情報の関連付けである。例えばhttpsを使って銀行や政府のWebサーバに接続する際、確認したいことがドメイン名の正しさだけでなく、むしろWebサーバの運用組織の方が重要であることがある。DANEはドメイン名の正しさを担保するが、ドメイン名が割り当てられた組織やその組織がサーバを運用していることを担保する仕組みではない。
　今後、Webサーバの認証に期待されること、すなわちドメイン名の正しさなのか運用組織の違いなのかによってDANEが使われる場面が違ってくると考えられる。また、DANEの実装や普及によってDNSSECがより厳格に運用される必要が出てくる可能性があり、DNSサーバの運用者に求められる業務が変わってくる可能性がある。DNSSECの運用には鍵の管理や導入のステップを検討する必要があるが[6][7]、DANEでは、更にリソースレコードの登録を正しく行うための業務が加わることになる。

以上