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

ドメイン名関連会議報告

2015年

第93回IETF Meeting報告（後編）

～dprive WGにおける話題／IETF全般における話題～

2015/08/26

今回のFROM JPRS増刊号では前回に引き続き、第93回IETF Meeting（以下、IETF 93）の内容について報告します。

dprive WGにおける話題

dpriveはDNS PRIVate Exchangeに由来しており、Pervasive Monitoring（*1）を回避するため、DNSトランザクションにおける機密性（confidentiality）を提供することを目的としています。

（*1）
広域かつ網羅的な通信の傍受・情報収集のこと。

DNSの通信ではUDP・TCPの双方が使われます。そのため、WGでは通信の暗号化の方式としてUDPをターゲットとした「DNS over DTLS」と、TCPをターゲットとした「TLS for DNS」の二つの標準化作業が進められています。

DNS over DTLS

DNS over DTLS（以下、DNSoD）は、DNSのUDP通信にDTLS（*2）を適用することで機密性を確保する提案です（draft-ietf-dprive-dnsodtls）。DNSoDはDNSのデフォルトのポート番号の53を用いる場合、53以外の新しいポート番号を用いる場合のいずれにも対応しています。

（*2）
Datagram Transport Layer Securityの略称。
UDPのようなデータグラムプロトコル（配送の成功・到達時間・到達順序が保証されないプロトコル）において、暗号通信を行うためのプロトコルです。

本提案では、DNSoDを標準化する動機として、

  • TCPでは、先頭のパケットが失われた場合に全体が再送されるまで後続のパケットが送信されず、通信のパフォーマンスが大きく低下してしまう「head-of-line blocking」と呼ばれる問題が発生しうる。
  • DTLSでは暗号通信の開始時に必要なパケットのやりとりが一往復追加されるのみであり、必要なコストが（TCPにおける）TLSに比べて低い。また、TCPでもTCP Fast Open（*3）を用いることで通信開始時のコストを軽減できるが、現在運用されているシステムではほとんど使えない。
（*3）
TCP Fast Open
TCPにおける接続の確立を簡略化することで通信開始までの時間を短縮する方式として、RFC 7413で定義されています。TCP Fast Openでは初回の接続確立時にサーバー側からクッキーを発行し、2回目以降の接続にそのクッキーを用いることで、接続の確立を簡略化します。

の2点を挙げています。

WGでは、プロトコルの設計に脆弱性があった場合、従来のSSL/TLSと同様のダウングレード攻撃（*4）を受けるのではないかという懸念点が示され、今後も継続して議論を進めていくことになりました。
（*4）
暗号通信の確立時に、より弱い暗号アルゴリズムや暗号を使わない通信に制限されてしまう機能を利用し、機密性の確保を妨害する攻撃手法。

TLS for DNS

TLS for DNSは、TLS（*5）をDNSに適用することで機密性を確保するための提案です（draft-ietf-dprive-start-tls-for-dns）。TLS for DNSはDNSのデフォルトのポート番号の53を用いる場合、53以外の新しいポート番号を用いる場合のいずれにも対応しています。

（*5）
Transport Layer Securityの略称。
TCPのようなコネクション型プロトコルにおいて、暗号通信を行うためのプロトコルです。従来の暗号通信規格であるSSLには致命的な脆弱性が発見されており、TLSへの移行が強く推奨されています。
TLS for DNSには既にいくつかの実装が開発されており、現在の提案文書ではUnbound、ldns/drill（*6）、digit（*7）、getdns（*8）における実装例が紹介されています。
（*6）
ldnsはNSD/Unboundの開発元であるオランダのNLnet Labsが開発しているDNSライブラリです。drillはBINDのdigコマンドと同等の機能を提供するコマンドラインツールで、ldnsを使って実装されています。
（*7）
米国南カリフォルニア大学情報科学研究所（ISI）内に設立されたANTLabが開発している、DNSの動作確認に利用するためのコマンドラインツールです。
（*8）
米国Verisign社とオランダのNLnet Labsが共同開発している、DNSライブラリ／APIです。

WGでは、新しいポート番号を用いる案、現在の53と新しいポート番号を併用する案、現在の53を継続使用しSTARTTLS（*9）で暗号通信に移行する案などの比較検討が必要であるという指摘があり、今後も継続して議論を進めていくことになりました。
（*9）
平文の通信から暗号通信に切り替える方法の一つ。SMTPやPOP3/IMAPなど電子メール関連のプロトコルにおける利用が標準化され、普及しています。

▽電子証明書情報のクライアントへの伝達

また、WGでは前述したDNS over DTLSとも共通する問題として、暗号通信に必要な電子証明書の情報をDNSクライアントにどのような形で知らせるかという問題が議論されました。会場からは、/etc/resolv.confファイルに設定を追加する、DHCPにオプションを追加するなどの方法がアイディアとして上がりました。

パディングオプション

2014年11月にセキュリティ研究者のHaya Shulman氏（*10）が、「Pretty Bad Privacy: Pitfalls of DNS Encryption」という論文を発表しました（関連URIを参照）。

（*10）
同氏は第一フラグメント便乗攻撃（1st-fragment piggybacking attacks）など、DNSセキュリティに関する論文を数多く発表しています。
論文では、DNSではデータサイズや問い合わせのパターンがいくつかに固定されているため、単なる暗号化だけでは機密性の確保には不十分であることなど、DNSの暗号化におけるプライバシー上の注意点が示されています。

この問題を解決するため、今回のWGではEDNS0を利用して暗号化前のDNSパケットにランダムなパディング（padding）（*11）を追加するためのオプションを定義するための提案が発表されました（draft-mayrhofer-edns0-padding）。
（*11）
データ長を調整するため、データの前後に無意味なデータを追加して長さを合わせること。

WGでは、

  • 標準化作業が進められている新しいバージョンのTLS（TLS 1.3）にはパディングの機能が含まれており、それを使うことでこの問題を回避できること
  • DNSデータが大きくなるプロトコル拡張はDoS攻撃につながりうること
  • EDNS0のサポートが不十分なDNSサーバーが誤動作する可能性があること
などが問題点として指摘され、今後も継続して議論を進めていくことになりました。

IETF全般における話題

Edward Snowden氏の登場

今回のIETF 93では会議参加者向けに、2014年に公開されたEdward Snowden氏（*12）のドキュメンタリー映画の上映会が開催されました。なお、この上映会は非公式プログラムとしてAgendaには掲載されず、参加者向けのメーリングリストでのみアナウンスされました（*13）。

（*12）
同氏は2013年に、米国国家安全保障局 (NSA) による極秘の監視計画「PRISM」の存在と、複数のインターネット関連大手企業が同計画に極秘裏に参加していたことを告発した人物として知られています。
（*13）
メーリングリストでアナウンスしたMark Nottingham氏のブログによると、上映会の参加者は約170人であったとのことです（関連URIを参照）。

上映会の後、サプライズゲストとしてSnowden氏本人がビデオチャットで登場し、参加者との間の議論・質疑応答の時間が設けられました。

同氏は、IETFの標準化活動は利用者のためであるべきであり、技術者は利用者の安全性を高めるために活動すべきであること（*14）、利用者のプライバシー保護のため、データの暗号化にとどまらずDNS問い合わせについても暗号化すべきであるとし、IETFによるDNSSECとDANEの標準化や最近のdprive WGの活動についても言及しました。
（*14）
本件については、2014年11月に発表されたIABの声明でも言及されています（関連URIを参照）。
今回の議論・質疑応答の状況は、ISOCの公式ブログでも報告されています（関連URIを参照）。

ITU事務総局長がTechnical Plenaryに登壇

今回のIETF 93の全体会議（Technical Plenary）に、国際電気通信連合（以下、ITU）の事務総局長を務める趙厚麟（Houlin Zhao）氏がゲストとして登壇しました。

ITUとIETFはいずれも、標準化団体と呼ばれるものの一つです。しかし、活動が国単位であり各加盟国の投票で標準仕様が決められるITUと、活動が個人単位で「大まかな同意と動いているコード（rough consensus and running code）」により標準仕様が決められるIETFとでは、団体の成り立ちや標準化活動への取り組みの姿勢などに大きな違いがあります。

趙氏は、「ITUの服装」であるスーツ・ネクタイ姿で登壇した後、壇上でネクタイを外し、「IETFの服装」であるTシャツ（*15）を着るというパフォーマンスを行いました。その上で、ITUによる「トップダウンの標準化」とIETFによる「ボトムアップの標準化」は標準化作業における重要な違いであるとし、今後、ITUとIETFの間の連携強化を図っていきたい旨を表明しました。

（*15）
同氏が参加したIETF 46（1999年6月に開催）で配布されたもの。

次回のIETF 94は横浜で開催

次回の第94回IETF Meeting（以下、IETF 94）は2015年11月1日から6日にかけ、横浜で開催されます。国内での開催は2009年11月に広島で開催されたIETF 76以来、6年ぶりとなります。

今回のIETF 93では、IETF 94のホストを務めるWIDE Projectの加藤朗氏から、開催地である横浜の紹介や前回の横浜開催時（2002年7月のIETF 54）からの日本の状況の変化、同時期に開催される関連ミーティングの紹介がありました。

IETF 94について紹介するWIDEプロジェクトの加藤朗氏（中央）

IETF 94について紹介するWIDEプロジェクトの加藤朗氏（中央）

JPRSはIETF 94のスポンサーとして、IETF 94の開催を支援しています。

関連URI

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