バックナンバー：vol.160

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2016/05/10━
                    ◆ FROM JPRS 増刊号 vol.160 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
            第95回IETF会合（ブエノスアイレス）報告（前編）
                     ～DNS関連WG・BOFにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年4月2日から8日にかけて、第95回IETF会合（以下、IETF 95）がアルゼン
チンのブエノスアイレスで開催されました。FROM JPRSではIETF 95と、その周
辺で開催された会議の内容について、前編と後編に分けて報告します。

今回のFROM JPRSでは、以下の項目に沿って会合の模様をお伝えします。

  ・dnsop WGにおける話題
    - IETF 94以降のRFC発行状況
    - 主な提案の内容と標準化作業の進捗状況
  ・arcing BOFにおける話題
    - 開催の背景
    - 今回の議論の内容と今後の方向性
  ・dprive WGにおける話題
    - IETF 94以降のRFC発行状況
    - 主な提案の内容と標準化作業の進捗状況
  ・saagにおける話題
    - 楕円曲線暗号を用いたNSEC5の評価

           ◇                     ◇                     ◇

■dnsop WGにおける話題

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。

▼IETF 94以降のRFC発行状況

前回のIETF 94から2016年5月10日現在までの間に5本のRFCが発行され、4本の
インターネットドラフト（以下、I-D）がRFC発行待ち（RFC Ed Queue）となっ
ています。

▽RFC発行

  ・ルートサーバーへのアクセス時間の短縮（RFC 7706）
  ・DNS用語の明確化（RFC 7719）
  ・DNSのTCPサポートにおける実装上の要求事項（RFC 7766）
  ・問い合わせ名の最小化（RFC 7816）
  ・EDNS0によるedns-tcp-keepaliveオプション（RFC 7828）

▽RFC発行待ち（RFC Ed Queue）

  ・共有アドレス空間（100.64.0.0/10）の逆引きローカルゾーンへの追加
    （draft-ietf-dnsop-rfc6598-rfc6303）
  ・EDNS0によるChain Query機能（draft-ietf-dnsop-edns-chain-query）
  ・EDNS0によるDNSクライアントのネットワーク情報の伝達
    （draft-ietf-dnsop-edns-client-subnet）
  ・DNSクッキー（draft-ietf-dnsop-cookies）

▼主な提案の内容と標準化作業の進捗状況

最近のdnsop WGでは、プロトコルの変更・拡張に関する活発な提案と標準化作
業が進められています。ここでは、FROM JPRS編集局が注目した提案の内容と
標準化作業の進行状況について紹介します。

▽クエリタイプANYのレスポンスサイズの小型化
  （draft-ietf-dnsop-refuse-any）

DNSリフレクター攻撃の防止のため、ANYリソースレコード（以下、RR）に対す
る応答の仕様を変更してサイズを小さくするという、プロトコル変更の提案で
す。

今回のWGでは知っているすべてのRRを返すという従来の動作に加え、応答サイ
ズの減少のため有効な一部のRRSetのみを返すことができるようにするという
動作の具体例として、CloudFlare（*1）のDNSサービスで実装されたHINFO RR
（ホストの情報）を返す案と、NSD（*2）で実装されたMX+A+AAAA RRを返す案
の二つが検討されました。その結果、双方の案を記述することとし、議論の結
果を見た上でワーキンググループラストコール（以下、WGLC）を実施すること
となりました。

（*1）CDNやクラウドを用いたDNSサービスなどを提供する米国の企業。

（*2）オランダのNLnet Labsが開発している、権威DNSサーバーの実装。

▽DNSの委任における要求事項
  （draft-wallstrom-dnsop-dns-delegation-requirements）

DNSの委任において親子それぞれのゾーンが正しく設定・運用されていない場
合、Lame Delegationを始めとするさまざまな問題の原因となります。本提案
では、提案者が開発メンバーの一人となっているDNSの設定チェックツール
Zonemaster（*3）を開発・運用する中で得られた知見を活かし、DNSの委任に
おける要求事項について、DNSプロトコルやパケットの取り扱いなどに求めら
れる項目がまとめられています。

（*3）スウェーデン（.se）のccTLDレジストリIISとフランス（.fr）のccTLD
      レジストリAFNICが共同開発している、DNSの設定確認・デバッグツール。
      https://www.zonemaster.net/

本提案では要求事項として、ドメイン名の有効性や権威DNSサーバーのIPアド
レスの到達性といった基本的なものから、TCP/UDP双方でのサービスの提供、
SOAやNSの設定内容、UDPにおけるパケットの切り詰め、DNSSEC関連の設定に至
るまでの、DNSの委任に関する要求事項が網羅的にまとめられています。

今回のWGでは本件について活発な議論が行われましたが、WGとして取り上げる
かについては明確な結論が出されず、今後メーリングリストで議論を続けてい
くこととなりました。

▽DNSSECのための暗号アルゴリズムの実装要求事項と利用指針
  （draft-wouters-sury-dnsop-algorithm-update）

DNSSECではさまざまな暗号アルゴリズムが用いられます。しかし、それらのア
ルゴリズムは計算機環境の変化やアルゴリズムの危殆（きたい）化などにより
使用が推奨されなくなる場合があります。

本提案では、フルリゾルバーと権威DNSサーバー間における相互運用性の確保
のため、その時点においてすべての実装でサポートが必須、あるいは推奨され
る暗号アルゴリズムの実装ガイドラインを作成することを目的としています。

今回のWGでは各暗号アルゴリズムを署名と検証に分けて分類・定義することや、
MUST+／SHOULD-／MAYなどといったレベルの付け方について議論されましたが
明確な結論は出されず、今後メーリングリストで議論を続けていくこととなり
ました。

▽HTTPを使ったDNS通信（draft-song-dns-wireformat-http）

DNSサービスの可用性を高めるため、DNSの通信をHTTPで伝達する方法を定義す
るための提案です。本提案では通常のDNS通信ができないネットワークやミド
ルボックス（*4）などの配下において、HTTPを用いたDNS通信を実現すること
を想定しています。

（*4）RFC 3234で定義される、通信路の間（middle）に存在する、通常のルー
      ティング以外の動作をする装置（box）の総称。ミドルボックスの例と
      して、ファイアーウォールやネットワークアドレス変換（NAT）装置、
      侵入検知システム（IDS）などが挙げられます。

WGではJSON（*5）でDNSパケットを記述すべきといった意見や、既存の名前解
決APIが対応していない問題などについて議論されましたが明確な結論は出さ
れず、今後も議論を続けていくこととなりました。

（*5）JavaScript Object Notation
      JavaScriptのオブジェクト表記方法に由来する簡便なデータ記述法。

▽NSEC/NSEC3の積極的な活用（draft-fujiwara-dnsop-nsec-aggressiveuse）

JPRSの藤原和典と慶應義塾大学大学院の加藤朗氏との共著で提案されている、
DNSSECの不在証明の仕組みを積極的に活用することでDNS水責め攻撃（*6）の
影響緩和を図る、プロトコル変更のための提案です。

（*6）DNS水責め攻撃の概要については、以下の資料をご参照ください。
      https://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf

WGでは、不在証明を用いてルートゾーンへの問い合わせを減らすことに特化し
た別の提案（draft-wkumari-dnsop-cheese-shop（*7））と併せた形で議論さ
れました。

（*7）このI-Dのタイトルに含まれる「cheese-shop」について、提案者はイ
      ギリスのコメディグループ「モンティ・パイソン」のスキット「The
      Cheese Shop」に由来するものであるとしています。このスキットは
      チーズ店を訪れた客がさまざまなチーズの名前を挙げ、店主が「在庫
      がない」を繰り返すというもので、その様子をルートサーバーに存在
      しない名前を繰り返し問い合わせる様子になぞらえたものと考えられ
      ます。

WGでの議論の結果、藤原らが提案しているNSEC/NSEC3の積極的な活用がより支
持され、draft-wkumari-dnsop-cheese-shopに記述された要素・考え方を藤原
らの提案に取り入れるよう、WGチェアから指示がありました。

WG終了後の4月10日に、WGチェアが本提案をWG Draftとして採択することを検
討する旨（Call for Adoption by WG Issued）を宣言しています。

■arcing BOFにおける話題

▼開催の背景

インターネットの名前解決システムには、DNS以外にもMulticast DNS（mDNS）
やTor（*8）で用いられているOnion routingなど、複数のシステムが混在・
併存しています。

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

こうしたDNS以外の名前解決システムも含め、複数のシステムが混在・併存し
ている環境における名前解決全般における問題を議論・検討する場として、
arcing（Alternative Resolution Contexts for Internet Naming）BOFが開催
されました。

▼今回の議論の内容と今後の方向性

今回のBOFでは問題点と検討対象の明確化のため、DNSの歴史やDNS以外の名前
解決システムの紹介とそれらに関する課題の認識が解説され、その後、利用者
ごとに異なる名前解決方法をどのように識別し、どのような手順で適用すべき
かを中心に議論が進められました。

今後のWG設立については、今回の議論の対象となったI-D（draft-lewis-
domain-names、draft-hardie-resolution-contexts、draft-trammell-inip-
pins）を更新し、WGの設立を前提としたBOFを次回のIETF 96で開催した上で決
める方がよいという意見が多く、メーリングリストでコメントを募集した上で
進めていくことがBOFチェアから示されました。

なお、今回のBOFはIABが主催しており、dnsop WGで検討が進められている特殊
用途ドメイン名（RFC 6761）に関する議論が、ここで取り扱う課題の一つにな
ることが見込まれます（*9）。

（*9）本件の詳細については、以下の第94回IETF Meeting報告をご参照くださ
      い。
      https://jprs.jp/related-info/event/2015/1207IETF.html

■dprive WGにおける話題

dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクションにおけ
る機密性（confidentiality）の提供を目的としています。

▼IETF 94以降のRFC発行状況

前回のIETF 94から2016年5月10日現在までの間に、2本のI-DがRFC発行待ち
（RFC Ed Queue）となっています。

▽RFC発行待ち（RFC Ed Queue）

  ・DNS over TLS（draft-ietf-dprive-dns-over-tls）
  ・パディングオプション（draft-ietf-dprive-edns0-padding）

▼主な提案の内容と標準化作業の進捗状況

▽DNS over DTLS（draft-ietf-dprive-dnsodtls）

DNS over DTLSは、TLSをUDPに対応させたDTLS（*10）をDNSに適用する提案で
す。

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

DTLSではフラグメントの仕様が定義されておらず、DTLSを利用する場合、上位
層においてフラグメントを回避する必要があります。そのため、今回のWGでは
フラグメントが発生しうる大きな応答についてはDNS応答のTCビットをセット
した上で切り詰めた応答を返すことによりDNS over TLSでの再問い合わせを促
し、フラグメントが発生した場合の取り扱いについてはI-Dから削除されるこ
ととなりました。

本提案については今後、内容のレビューを進めた上でWGLCを実施する予定と
なっています。

▽DNS over TLS/DTLSにおける認証とプロファイル
  （draft-ietf-dprive-dtls-and-tls-profiles）

本提案は、DNS over TLS/DTLSにおいてDNSクライアントがDNSサーバーを認証
する方法に加え、DNS over TLS/DTLSを実装するために必要なプロファイル
（*11）の内容について定義します。

（*11）暗号通信を確立する際に必要な情報を記述するファイル。

今回のWGでは認証部分のプロファイル定義として、以下の3種類が提案されま
した。

  ・Strict（厳密に認証・暗号化し、中間者攻撃や盗聴を防ぐ）
  ・Opportunistic（暗号化を試みるが相手の正当性は検証しない）
  ・No Privacy（そもそもTLSを用いない）

提案を元にサーバーの認証方法について議論され、Strictでなければプライバ
シーは確保できないのではないかという意見や認証にDANE（*12）を用いる解
決法の提案、複雑な方式では普及しないのではないかといった意見などさまざ
まな議論が交わされ、今後も継続して議論を進めていくこととなりました。

（*12）DNS-based Authentication of Named Entitiesの略称。
       DNSを用いてデジタル証明書の安全な配送や証明書とサーバーの関連付
       けの正しさを検証するためのプロトコル。DANEではこれをDNSの委任関
       係を用いて検証することにより、認証局の介在なしにサーバーの正当
       性を検証することが可能になります。

■saagにおける話題

セキュリティエリア全般にまたがる話題を横断的に取り扱うグループsaag
（Security Area Advisory Group）のオープンミーティングにおいて、NSEC3
を改良した不在証明方式であるNSEC5（*13）を楕円曲線暗号（Elliptic
Curve Cryptography）を用いて評価した結果の報告が行われました。

（*13）NSEC4は既に提案されていたため、NSEC5として提案されました。

▼楕円曲線暗号を用いたNSEC5の評価（draft-vcelak-nsec5）

現在のDNSSECの不在証明方式であるNSEC3はゾーン情報の列挙を困難にするた
め、名前情報をハッシュした結果を利用します。しかし、NSEC3ではハッシュ
の総当たりにより、ゾーン情報の列挙ができ得るという問題が指摘されていま
す（*14）。

（*14）The nsec3walker tool
       https://dnscurve.org/nsec3walker.html

NSEC5はこの問題を解決するための不在証明方式として、2014年に論文の形で
発表されました（*15）。その後、論文の仕様に基づいたI-Dが2015年に発表さ
れています。NSEC5では公開鍵暗号方式により不在証明の結果を暗号化する機
能を加えることで、総当たりによるゾーン情報の列挙を防止しています。

（*15）NSEC5: Provably Preventing DNSSEC Zone Enumeration
       https://www.cs.bu.edu/~goldbe/papers/nsec5.pdf

今回のsaagではNSEC5の暗号方式として楕円曲線暗号を用いた場合の応答サイ
ズを従来のNSEC・NSEC3の応答サイズと比較した結果、NSEC3よりわずかに大き
くなる程度に応答サイズを収めることが可能であり、応答サイズの観点からは
実運用可能であると考えられることが報告されました。

■後編の内容について

後編となる次回のFROM JPRS増刊号では、レジストリ関連の状況と、IETFに併
設される形で開催された各種会合における話題を中心にお伝えします。

           ◇                     ◇                     ◇

◎関連URI

  - 95 Meeting Index
    https://www.ietf.org/meeting/95/
    （IETF 95公式ページ）

  - IETF 95 meeting materials
    https://datatracker.ietf.org/meeting/95/materials.html
    （IETF 95発表資料一覧）

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - Alternative Resolution Contexts for Internet Naming (arcing)
    https://datatracker.ietf.org/wg/arcing/charter/
    （arcing BOF公式ページ）

  - DNS PRIVate Exchange (dprive) - Charter
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - Sec Area Wiki
    https://trac.tools.ietf.org/area/sec/trac/
    （IETF Security Area公式Wikiページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：https://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：https://jprs.jp/mail/henkou.html
■バックナンバー：https://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンは、Windowsをお使いの方はMSゴシック、Macをお使いの方は
Osaka等幅などの「等幅フォント」で最適にご覧いただけます。

当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
https://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
https://jprs.jp/
Copyright (C), 2016 Japan Registry Services Co., Ltd.