JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

ドメイン名関連会議報告

2012年

第84回IETF Meeting報告（1）

～DANEの動向に関する話題～

2012/08/31

今回で84回目となるIETF Meeting（以下、IETF84）が2012年7月29日から8月3日にかけて、カナダのバンクーバーで開催されました。FROM JPRSでは今回から2回にわたり、IETF84で報告・議論されたさまざまな話題の中から、ドメイン名／DNSに関する話題を中心にお伝えします。
第1回目となる今回は、ここ数回のIETFにおいて集中的に作業が進められ、2012年8月に基本プロトコルが標準化されたDANE（*1）の動向について報告します。

(*1)

DANEの名称は「DNS-based Authentication of Named Entities」に由来しています。

dane WGの状況

dane（*2）WGでは、DNSを用いたデジタル証明書（以下、証明書）の安全な配送や、証明書とサーバーの関連付けの正しさを検証できるようにするためのプロトコルの標準化作業を進めています。

(*2)

IETFのWG名は小文字で表記されます。

会議会場となったホテルハイアット・リージェンシー・バンクーバー

会議会場となったホテルハイアット・リージェンシー・バンクーバー

DANEの基本仕様の標準化作業が完了

WGで標準化作業を進めていたDANEの基本仕様が、2012年8月にRFC 6698として発行されました。DANEは、特にWebにおいて広く普及しているTLS/SSL（*3）の信頼性確保を、既存のDNSインフラによって実現することを目的としています。

(*3)
Transport Layer Security/Secure Sockets Layerの略。
安全な通信を行うためのプロトコル。TLSの前身となったSSLは米国ネットスケープコミュニケーションズ社（当時）により開発／実装され、現在のTLSはIETFにより標準化が進められています。
ここでは、DANEが開発目標としたTLS/SSLにおける証明書の正当性検証の現在の状況、DANEにより実現される具体的な内容、WGの活動開始に至るまでの経緯などについて、改めておさらいします。

▽現在のTLS/SSLではX.509による証明書を正当性検証に利用

現在のインターネットではTLS/SSLの信頼性確保において必要となる証明書の正当性検証に、ITU-T（*4）が定めたX.509で規定された認証局（CA）の階層構造が広く用いられています。

(*4)

国際連合の専門機関の一つである国際電気通信連合（ITU）の部門の一つで、通信分野における規格の策定を担当しています。
X.509 の階層構造ではルート認証局が発行するルート証明書が、全体の信頼性の根本となっています。ルート認証局は自らの正当性を自分自身が証明することになるため、ルート認証局を運営する組織はそのシステムの信頼性や生成／使用する暗号鍵の取り扱いに、細心の注意を払う必要があります。

▽2011年に複数のルート認証局がクラックされる事件が発生、実害も報告

しかし、2011年に複数のルート認証局が外部からの侵入を受け、システムをクラックされる事件が相次いで発生しました。そのうち、オランダの DigiNotar社（現在は破産、業務停止）のルート認証局がクラックされた事件では、実際に500以上もの偽のサーバー証明書が不正発行され、その一 部がTLS/SSL通信の盗聴に悪用されるなど、インターネットの安全な利用に対する大きな脅威となりました。

▽DANEではDNSSECの信頼の連鎖を証明書の正当性検証に利用

一方、2010年7月にルートゾーンにおけるDNSSECの運用が開始され、続く2011年には.jpや.com/.netなどを含む数多くのTLDにおいてDNSSECの正式運用が開始されたことにより、利用者がDNSSECを利用可能な環境が整いつつあります。
DNSSECではルートゾーンからの信頼の連鎖により、DNSデータの正当性を検証します。つまり、

(1)
DNSデータとして公開鍵や証明書の情報を格納できるように、プロトコルを標準化する
(2)
それらのDNSデータが格納されているゾーンまでの信頼の連鎖を、DNSSECで確立する

ことにより、従来のX.509におけるルート認証局からの階層構造を用いた証明書の検証をルートゾーンからのドメイン名の階層構造を用いて実現することが、原理的に可能になります。
このこと自体はDNSSECの開発段階から専門家の間で認識されていましたが、DNSSEC自体の標準化と実環境への導入の遅れにより、標準化のための本格的な活動は、これまで積極的に進められていませんでした。
そして、最近のDNSSECの普及促進と利用環境の整備（＝上記（2）の実現）を受け、上記（1）を実現するためのプロトコルの標準化を目的としてdane WGが組織され、標準化作業が進められることとなりました。

TLS/SSLのための枠組みとして「TLSAリソースレコード」を新規導入

前述したようにdane WGでは、TLS/SSLにおける証明書の正当性検証に用いるための、DANEの標準化が目的とされました。
DANE では証明書の検証に利用する証明書そのものや公開鍵を格納するためのリソースレコードとして、TLSAリソースレコードが新たに定義されました。なお、 RFC 6698ではTLSAは何らかの略称ではなくリソースレコードの名称として定義されており、今回標準化されたプロトコルは「DANE TLSA」と呼ばれることになります。

IETF84における状況

IETF84 では基本プロトコルであるDANE TLSAの標準化完了を受け、secureSMTP（*5）、S/MIME（*6）、XMPP（*7）に対応するためのプロトコルの標準化が議論されまし た。いずれも作業進行中であり、標準化に向けた作業を継続していくこととなりました。

(*5)
Simple Mail Transfer Protocolの略称。
電子メールを送信するためのプロトコルです。メールサーバー間での電子メールのやり取りや、メールソフトなどのクライアントからメールサーバーに電子メールを送信する際に用いられます。
(*6)
Secure Multipurpose Internet Mail Extensionsの略称。
電子メールを暗号化するためのプロトコルの一つです。最初のバージョン米国RSA Data Security社によって提案され、IETFにより標準化されました。
(*7)
eXtensible Messaging and Presence Protocolの略称。
インスタントメッセンジャー（以下、IM）において、メッセージの交換やログイン状況の通知などに使われるプロトコルです。米国Jabber社によって開発されたIM「Jabber」のプロトコルがもととなっており、IETFで標準化されました。

最後にdane WGの今後について議論され、DANE TLSAの標準化完了を受け、現在進行中の標準化作業の完了後、WGを一時休止（hiatus）の状態とすることがほぼ合意されました。なお、従来から WGではDANE TLSAに加え、IPsecにおける証明書の正当性検証に関する標準化も目的とされていましたが、今回のIETF84において、IPsecにおける標準化 は目的から外されることとなりました（*8）。

(*8)
理由の一つとして、IPsecの機能拡張のためのWGとしてipsecme WGが設立済であることが挙げられました。

次回の内容について

次回のFROM JPRSでは、IETF84におけるdane以外のDNS関連WG、plenary（全体会議）におけるトピックスなどについてお伝えします。

関連URI

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。