第92回IETF Meeting報告（後編）

今回のFROM JPRS増刊号では、第92回IETF Meeting（以下、IETF 92）の後編として、dnsop WGにおける話題の続きと、dprive WGにおける話題について報告します。

特殊な名前の取り扱い――.onion

Tor（トーア）は、TCP/IPにおける接続経路（どの機器がどのネットワーク経由で接続したか）の匿名性を高めるための技術で、米国のTor Project, Incにより開発されています。

Torでは利用者のみがアクセス可能な秘匿サービス（hidden services）の名前として、「公開鍵のハッシュ.onion」という形式が使われています（*1）。これはTorのネットワーク内でのみ使用可能な、いわゆる内部利用名（internal name）の一つです。

▽.onionの予約に関する提案

今回のWGではTor ProjectのJacob Appelbaum氏から、

• .onionはRFC 6761で定められる「特殊用途ドメイン名（Special-Use Domain Names）」の条件を満たしており、IESG（*2）によって予約されるべきものであること
• もし.onionが予約されない、あるいは予約が遅れた場合、以下の不具合が発生・継続する危険性があり、作業を迅速に進める必要があること
  • 2015年10月1日をもって.onionを用いた内部利用名に対する証明書が無効化され、Tor上の暗号通信のセキュリティレベルが低下する
  • リゾルバーにおける特殊処理が実施されず、利用者がどんな秘匿サービス名を検索したかがDNS（ルートサーバー）に流出し続ける
  • アプリケーションにおける特殊処理が実施されず、クライアントからリゾルバーに対し無駄な問い合わせが送られ続ける

という提案がありました（draft-appelbaum-dnsop-onion-tld）。

この背景には、2011年から始まった新gTLD創設プログラムに伴って顕在化した、名前衝突（Name Collision）（*3）の問題があります。名前衝突によるセキュリティリスクを回避するため、CA/Browser Forum（*4）は内部利用名に対する証明書の新規発行の禁止と期限を設定した上での発行済み証明書の無効化（revoke）の実施を表明しており、.onionはこの影響を受けることになります。

▽提案の理由と議論の状況

この問題そのものは以前から指摘されており、.onionを含む既存のネットワークサービスで用いられている主な疑似TLD（pseudo TLD）をIESGで予約するべしという提案が、2013年に発表されています（grothoff-iesg-special-use-p2p-names）。今回の提案を発表したAppelbaum氏は、この提案の共著者でもあります。

Appelbaum氏は.onionの予約を別提案とした理由として、Torが広く利用されており（*5）、かつ.onionの証明書が無効化される期日が迫っていることから、緊急に作業を進める必要があったことを挙げています（*6）。

今回のWGでは、RFC 6761に記述された特殊用途ドメイン名の振り返りと、.onionに関する問題の明確化が行われました。会場からは、単に予約するだけではルートサーバーへの問い合わせの流出は回避できないため、AS112プロジェクト（*7）と同様、.onionをルートゾーンから委任するのが良いのではないかというコメントがありました。

今回のWGでは本件に関する明確な結論は出されず、問題解決に向けた関係者による電話会議での臨時ミーティングを、5月に別途開催することとなりました。

EDNS0の対応状況調査

EDNS0はExtension Mechanisms for DNSに由来する、DNSを機能拡張するための規格です（*8）。EDNS0はDNSのUDPメッセージサイズの拡大や応答コード・フラグの拡張など、さまざまな拡張機能をサポートしており、DNSを機能拡張する際のベースとなるプロトコルとして、広く利用されています（*9）。
今回のWGではEDNS0の拡張機能への対応状況の調査結果と、それにより判明した問題の内容が発表されました（draft-andrews-dns-no-response-issue）。

発表では、調査対象をルート及びTLD、Alexa（*10）のランキングから所定の方法で抽出したドメイン名の権威DNSサーバーとしたこと、調査方法として、対象の権威DNSサーバーに対しEDNS0のバージョン・オプション・フラグなどを変化させたさまざまな問い合わせを送る方法を採用したことが説明されました。

また、調査結果として、本来返してはならないフォーマットエラー（FORMERR）やバージョンの不一致エラー（BADVERS）、不適切なパケットの切り詰め処理や無応答など、EDNS0の実装エラーに起因すると考えられるさまざまな問題が判明した旨が報告され、これらはEDNS0を利用した新しいDNSプロトコルの普及を図る上での障害となりうることが、問題点として共有されました。

発表では問題解決のためのステップとして、ファイアーウォールや権威DNSサーバー、ゾーン管理者やDNSホスティングプロバイダーへの連絡、オンライン版のDNSチェッカーの開発などが挙げられました。

DNS用語の明確化

DNSは現在、数十本以上のRFCによりプロトコル仕様が定義されています。それらの仕様を定義するための用語は、各実装者・開発者・運用者がそれぞれに定義したものが使われているのが現状であり、また長年にわたって使われ続ける間に、最初の定義とは異なってきているものも存在しています。

このことは、DNSを理解・解説する際の障害の一つとなっています。そのため、これまでに発行されたDNS関連のRFCで定義された数多くのDNS用語をまとめた一つのドキュメントを作成し、用語を明確化するための作業が開始されました（draft-hoffman-dns-terminology）。本文書は、JPRSの藤原が共著者となっています。

今回のWGでは、本ドキュメントでは既存の用語を解説・明確化することに集中し、新規の用語や新しい提案は別のドキュメントで規定することが再確認されました。

この提案はIETF 92終了後の2015年4月14日にWGドキュメントとなり（draft-ietf-dnsop-dns-terminology）、今後WGとして標準化作業を進めていくこととなりました。
dpriveはDNS PRIVate Exchangeに由来しており、Pervasive Monitoring（*11）に対抗するためのDNSトランザクションにおける機密性（confidentiality）の提供（*12）を目的としています。

実装案の検討状況

前回のIETF 91では、候補となる以下の三つの実装案が提案されました。

このうち、1.のTLSによる通信路の保護と2.のSTARTTLSによる暗号化では、DNSの暗号通信にTCPを用いることが前提条件となっています。
今回のWGではこれらの実装案のうちの1.と2.を統合し、一本化する提案が発表されました（draft-hzhwm-dprive-start-tls-for-dns）。この提案では、まず別ポートでTLSを試し、次にポート53/TCPにSTARTTLSに相当するDNS問い合わせを送ることでTLSモードへの移行を試す、という形式を採用しています。

会議では、この提案が現時点における最有力候補として、今後も継続して提案の検討が進められることとなりました。

次回の第93回IETF Meeting（IETF 93）は2015年7月19日から24日にかけ、チェコのプラハで開催される予定です。

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