バックナンバー：vol.182

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2019/04/23━
                    ◆ FROM JPRS 増刊号 vol.182 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                   第104回IETF Meeting（プラハ）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年3月23日から29日にかけて、第104回IETF Meeting（以下、IETF 104）が
チェコのプラハで開催されました。

今回のFROM JPRSでは、IETF 104とその周辺で開催された会合の中から、FROM
JPRS編集局が注目した以下の話題をお伝えします。

  ・IETF 103以降のDNS関連RFCの発行状況
    - DNS Stateful Operationsの仕様
    - トラストアンカーの状況を外部から調べる方法
    - アンダースコア名のレジストリ
    - アンダースコア名のレジストリの開始に伴う定義済みラベルの仕様変更
    - 自動証明書管理環境（ACME）の仕様
  ・dnsop WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・doh WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・dprive WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  ・KSK Futures BoFにおける話題
  ・Side Meetingの状況
    - 「Various issues raised in the DoH context」Meetingの状況
    - 「Registry / Security Lock」Meetingの状況
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■IETF 103以降のDNS関連RFCの発行状況

前回のIETF 103以降に発行された、DNS関連の主なRFCの内容は以下の通りです。

なお、期間中に発行された、RFC 8482（問い合わせタイプANYの応答サイズの
小型化）、RFC 8499（DNS用語集）、RFC 8501（ISPのためのIPv6逆引きDNSの
管理運用手法と考慮事項）についての詳細は、過去のドメイン名関連会議報告
をご参照ください。
https://jprs.jp/related-info/event/2018/1213IETF.html

▼DNS Stateful Operationsの仕様

  ・RFC 8490: DNS Stateful Operations
    （Standards Track、draft-ietf-dnsop-session-signal）

    RFC 8490は、DNS Stateful Operations（DSO）の仕様を定義します。

    DNSの通信は、一組の問い合わせと応答で完結する形が基本です。フルリ
    ゾルバー（キャッシュDNSサーバー）や権威DNSサーバーとの通信は通信相
    手ごとの状態（ステート）を保持しない、ステートレスの形で行われます。

    本RFCは、従来のDNSプロトコルとは全く異なる形式で、サーバー側からの
    メッセージ開始といった従来のDNSにはなかった機能を実現するための新
    しいOPCODE[*1]と、その通信に使うDSOメッセージの構文を定義します。

    [*1] DNSメッセージにおいて、問い合わせの種類を指定する番号。

    DSOは、現在dnssd WGで標準化作業が進められているDNSのプッシュ通知に
    利用されます。プッシュ通知では、通信のリクエストがサーバー側から開
    始されます。

▼トラストアンカーの状況を外部から調べる方法

  ・RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC
    （Standards Track、draft-ietf-dnsop-kskroll-sentinel）

    RFC 8509は、DNSクエリによって、DNSSECバリデーターが使用しているト
    ラストアンカーを外部から調べるための仕組みを定義します。

    RFC 8509に対応したDNSSECバリデーターは、「sentinel-is-ta-<鍵タグ>」
    と「sentinel-is-not-ta-<鍵タグ>」の二つのラベルを特別扱いします。
    これらのラベルを使った応答の変化を調べることで、KSKロールオーバー
    におけるトラストアンカーの更新状況を、外部から確認できます。

    なお、外部の研究者が自身のドメイン名を使って状況を確認する場合の例
    が、RFC 8509のAppendix Aにまとめられています。

▼アンダースコア名のレジストリ

  ・RFC 8552: Scoped Interpretation of DNS Resource Records through
              "Underscored" Naming of Attribute Leaves
    （Best Current Practice、draft-ietf-dnsop-attrleaf）

    RFC 8552は後述するRFC 8553と共に標準化され、アンダースコア（_）で
    始まるラベルを単一のテーブルで管理するレジストリをIANAに作ります。

    RFC 8552の発行によりアンダースコアで始まるラベルの割り当てが一元管
    理され、プロトコル間でのラベルの衝突を避けられるようになります。

    IANAに作られたレジストリの登録状況は、次のURIで公開されています。
    https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

▼アンダースコア名のレジストリの開始に伴う定義済みラベルの仕様変更

  ・RFC 8553: DNS AttrLeaf Changes:
              Fixing Specifications That Use Underscored Node Names
    （Best Current Practice、draft-ietf-dnsop-attrleaf-fix）

    RFC 8553は前述したRFC 8552の発行に伴い、発行済みのRFCで定義済みの
    アンダースコアで始まるラベルを、既存のソフトウェアや運用手法を維持
    しながら、IANAに作られたレジストリの仕様に合致させるための変更点に
    ついてまとめたものです。

▼自動証明書管理環境（ACME）の仕様

  ・RFC 8555: Automatic Certificate Management Environment (ACME)
    （Standards Track、draft-ietf-acme-acme）

    RFC 8555は、Automatic Certificate Management Environment（ACME）の
    仕様を定義します。

    ACMEは「自動証明書管理環境」を意味しており、証明書の管理を自動化す
    るためのプロトコルです。証明書の検証・発行・失効などの一連のプロセ
    スを自動化し、運用の負担を軽減することを目的としています。

    ACMEでは、証明書発行対象となるドメイン名の管理権限を確認する方法の
    一つとして、DNSを利用した「dns-01」を定義しています。dns-01では
    「_acme-challenge」というアンダースコアで始まるラベルを使って、証
    明書の発行対象となるドメイン名の管理権限を有していることを検証して
    います。

■dnsop WGにおける話題

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

▼議論された提案の内容と標準化作業の進行状況

議論する項目が多いため、今回のIETF 104でもdnsop WGが2回開催されました。
1回目がIETF Hackathon[*2]の状況と既存の提案の標準化作業の状況確認と議
論、2回目が新たな提案の議論に割り当てられました。

[*2] Hackathon（ハッカソン）はエンジニアが集中的に共同作業をする場を意
     味しています。IETFではIETF 92からHackathonが実施されており、新し
     く標準化された、あるいは標準化作業中のプロトコルの実験実装の試作
     が、集中的に行われています。

▽DNSクッキーにおけるサーバークッキー作成のアルゴリズム
  （draft-sury-toorop-dns-cookies-algorithms）

DNSクッキー[*3]において、クッキーを作成するアルゴリズムを定義するため
の提案です。

[*3] HTTPで利用されているクッキーと同様の仕組みをDNSで実現し、キャッ
     シュポイズニング対策に用いるための仕組みです。

DNSクッキーの仕様を定義したRFC 7873では、サーバークッキー[*4]のアルゴ
リズムとして何を採用するかは、サーバーソフトウェアの実装者の判断に委ね
られています。そのため、IP Anycast[*5]を用いて2種類以上のサーバー実装
を共存させる際、各サーバー実装間におけるサーバークッキーの相互運用性が
確保できないことが問題となりました[*6]。

[*4] DNSクッキーには問い合わせ側で付加するクライアントクッキーと応答側
     で付加するサーバークッキーの2種類があり、それぞれのクッキーを使っ
     て相手を相互に確認します。

[*5] IP Anycastの詳細は、JPRS用語辞典をご参照ください。
     https://jprs.jp/glossary/index.php?ID=0108

[*6] DNSクッキーとサーバークッキーの取り扱いに関する運用上の問題点につ
     いての詳細は、過去のドメイン名関連会議報告をご参照ください。
     https://jprs.jp/related-info/event/2018/0829IETF.html

本提案では、クッキーを作成するための実装必須かつデフォルトのアルゴリズ
ムとして、SipHash-2.4[*7]を指定しています。

[*7] Jean-Philippe Aumasson氏とDaniel J. Bernstein氏が考案した、高速な
     ハッシュ関数。

発表では、提案の方式をBIND 9・PowerDNS・NSD・Knot DNS・Unboundで実装・
テストしたことが紹介され、その際に発見された問題点を踏まえ、提案を更新
する予定であることが報告されました。

▽DNSにおけるエラーコードの拡張（draft-ietf-dnsop-extended-error）

EDNS0[*8]を用いてDNSエラーの原因に関する追加情報を提供する方式を定義す
る、プロトコル拡張の提案です。

[*8] RFC 6891で定義されるDNSの拡張方式で、バージョン番号を示すために
     EDNS0またはEDNS(0)と呼ばれます。詳細については、JPRS用語辞典をご
     参照ください。
     https://jprs.jp/glossary/index.php?ID=0147

現在のDNSSECでは検証においてエラーが発生した場合、従来のDNSにおける名
前解決エラーの場合と同様、SERVFAIL応答を返します。しかし、SERVFAIL応答
はサーバー側で名前解決エラーが発生したことのみを示しており、その原因が
何なのかを示す追加情報は含まれません。

本提案では、EDNS0を用いてエラーコードを拡張するための「Extended DNS 
Error (EDE)」オプションと、情報を返すための「Extended DNS Error Code」
を定義することで、エラーの原因に関する追加情報を問い合わせ元に返せるよ
うにします。

発表では、UnboundとKnot Resolverに本提案を実装・試験したことが紹介され、
今後、試験により得られた結果を提案に反映する予定であることが報告されま
した。

▽DNSSECにおけるアルゴリズムの実装要件と使用の指針
  （draft-ietf-dnsop-algorithm-update）

DNSSECを長期にわたって安全に保つためにアルゴリズムの推奨事項を更新し、
各実装における相互運用性を確保するため、現在の定義であるRFC 6944を置き
換えるための提案です。

現在のRFC 6944ではダイジェストアルゴリズムには規定がなく、署名アルゴリ
ズムはRSASHA1がMust Implement（実装必須）、RSASHA256やECDSAが
Recommended to implement（実装推奨）、他はOptional（任意）とされていま
す。

本提案では、古いSHA-1[*9]を用いたアルゴリズムをMUST NOT（禁止）とし、
より安全な方式であるSHA-256[*10]を用いたRSASHA256、楕円曲線暗号[*11]を
用いたECDSAP256SHA256をMUST（必須）とする変更が行われています。また、
GOSTは使われているアルゴリズムが新しいものに置き換わったため、禁止とさ
れています。

[*9] SHA-1は米国NISTにより、2011年に非推奨とされています。
     Secure Hashing - Approved Algorithms
     http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
     （米国国立標準技術研究所（NIST）による勧告）

[*10] 電子署名に使われる、代表的なハッシュ関数の一つ。

[*11] RSA暗号に比べ、より短い鍵長で同等の安全性を提供可能な暗号方式。

IETF 104終了後の4月11日に、IESGが本提案をProposed Standard RFCとして発
行することを承認しました。その後、4月22日にRFC発行待ち（RFC Ed Queue）
の状態となっています。

■doh WGにおける話題

dohはDNS over HTTPS（DoH）に由来し、DNSの通信をHTTPSの通信路で実現する
ため、DNSクエリとレスポンスのエンコードを標準化することを目的としてい
ます。

▼議論された提案の内容と標準化作業の進行状況

▽DoHサーバーのクライアントへの伝達
  （draft-ietf-doh-resolver-associated-doh）

IETF 102で開催されたdriu BOF[*12]における議論を受けた、DoHをサポートす
るサーバー（DoHサーバー）へのアクセス方法や利用方法をクライアントに伝
える方法を定義する提案です。

[*12] driu BOFと行われた議論についての詳細は、過去のドメイン名関連会議
      報告をご参照ください。
      https://jprs.jp/related-info/event/2018/0829IETF.html

本提案では、クライアントがDoHサーバーの情報を得るための複数の方法を定
義しています。ネットワーク管理者は、それらを使って利用者にDoHサーバー
の情報を提供できます。

本提案では、以下の三つの方法を定義しています。

  - HTTPS経由で、DoHサーバーのURIを得る
  - DNS経由で、DoHサーバーのURIを得る
  - DNS経由で、DoHサーバーのIPアドレスを得る

WGでは、DNSのサービスが大規模な事業者に集中するのではという懸念や、各
国におけるブロッキングの問題、VPNや企業ネットワークにおけるDoHの使用な
どについて議論されました。

■dprive WGにおける話題

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

▼議論された提案の内容と標準化作業の進行状況

▽リゾルバーと権威DNSサーバーの間における通信の暗号化

dprive WGの当初の目標であった、スタブリゾルバーとフルリゾルバー間の通
信のプライバシー確保に関する標準化作業は、Phase 1として完了しています。
標準化の詳細は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2018/0420IETF.html

dprive WGではPhase 2として、フルリゾルバーと権威DNSサーバー間の通信の
暗号化を検討しており、そのための要求条件と実装案の議論を開始しています。

今回のWGでは、DNSSECとの組み合わせや、DNS over TLS（DoT）・DoHとの組み
合わせにおけるアイデアが提案・議論されました。それぞれのアイデアについ
ては現時点では結論は出されず、今後、WGで議論が進められる予定です。

▽DNSにおけるプライバシー上の考慮点
  （draft-bortzmeyer-dprive-rfc7626-bis）

本提案は、DNSにおけるプライバシー上の要考慮点をまとめたRFC 7626を、そ
の後の標準化の状況を反映する形で更新するものです。

今回、IETF 103からの更新内容として、

  - DoTとDoHの標準化と普及による影響
  - EDNS Client SubnetやDNSクッキーなど、DNSのデータにおける考察
  - 暗号化されたDNS通信路への攻撃
  - DoTやDoHヘッダーの分析
  - 暗号通信を提供する外部のDNSサービスに対するブロッキング

に関する記述を追加したことが報告されました。

WGでは、実際にパブリックDNSサービスでDoT・DoHをサポートしているGoogle・
Cloudflareなどのプライバシーポリシーが比較され、議論が行われました。

■KSK Futures BoFにおける話題

前回のIETF 103ではSide Meetingとして開催されたKSK Futures BoFが、IETF
が取り組むべき課題であるという認識が高まったことを受け、今回は正式な
BoFとして開催されました。これまでに行われた議論についての詳細は、過去
のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2018/1213IETF.html

今回のBoFも、IANAが次回のルートゾーンKSKロールオーバーをどのように進め
ていくかを検討するためのインプットとして、意見を広く募集することを目的
として開催されました。

会場からは、次回の実施時期、今後の実施頻度、テスト方法、量子暗号の影響
の考慮、スタンバイキーの運用、今後のアナウンスの仕方、運用者からの
フィードバックの収集など、さまざまな項目に関する意見が寄せられました。
また、寄せられた意見は改めてksk-rolloverメーリングリスト[*13]にも投稿
することが強く推奨され、メーリングリストで議論が継続されています。

[*13] ksk-rollover Info Page
      https://mm.icann.org/listinfo/ksk-rollover

■Side Meetingの状況

▼「Various issues raised in the DoH context」Meetingの状況

DoHはプロトコル仕様がRFC 8484として標準化されましたが、その運用・利用
についてはまだ議論が不十分な状態であり、さまざまな懸念が指摘されていま
す。今回のSide Meetingは、DoHに関する具体的な問題点の洗い出しと議論す
る場を決めることを目的として、AFNICのStephane Bortzmeyer氏の呼び掛けに
より開催されました。

Side Meetingではdoh WGでも議論された以下の項目を含む、さまざまな問題点
が共有・議論されました。

  - IETFはロングタイムソリューションを考える上で、もっとデプロイ（普及）
    のモデルを考えるべき
  - 中央集権になるのは避けるべき
  - 政府からの介入も念頭に置くべき
  - DoHの問題はプロトコルの問題ではなく、ユーザーのプライバシー・デバ
    イス管理・ネットワークオペレーションの問題である

DoHの問題点について、doh WGと本Side Meetingを通じ約2.5時間の長時間にわ
たって議論が行われましたが、議論する場をどこにするかの結論は出ませんで
した。そのため、当面doh WGのメーリングリストを使い継続して議論を進めて
いくことになりました。

▼「Registry / Security Lock」Meetingの状況

登録情報の不正書き換えによるドメイン名ハイジャックを防ぐ手段の一つであ
る「レジストリロック」の標準化について議論するため、RDAP[*14]やEPP[*15]
の拡張について検討しているregext WGのSide Meetingとして、nic.atの
Alexander Mayrhofer氏の呼び掛けにより開催されました。

[*14] Registration Data Access Protocolの略称。
      登録情報にアクセスするためのプロトコル。URIによりデータが渡され、
      JSON（JavaScript Object Notation：JavaScriptのオブジェクト表記方
      法に由来する簡便なデータ記述法）の形式で応答が返されます。

[*15] Extensible Provisioning Protocolの略称。
      ドメイン名の登録情報をレジストリとレジストラの間で交換するために
      設計されたプロトコルです。拡張性の高さを特長としており、ドメイン
      名だけでなくIPアドレスなど、他の情報のレジストリにおける利用も考
      慮されています。

Side Meetingの参加者はドメイン名レジストリやレジストラ、RIRの関係者が
中心となっており、レジストリロックの標準化の必要性に関する議論が進めら
れました。

今回のMeetingでは、それぞれのレジストリにおけるビジネスの考え方やセ
キュリティに対する方針、使われる用語などに違いがあることから、今後の議
論を進めるため、まずは用語の共通化・標準化のための活動を進めることにな
りました。

■次回のIETF Meetingについて

次回の第105回IETF Meeting（IETF 105）は2019年7月20日から26日にかけ、カ
ナダのモントリオールで開催されます。

          ◇                     ◇                     ◇

◎関連URI

  - 104 Meeting Index
    https://www.ietf.org/how/meetings/104/
    （IETF 104公式ページ）

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

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

  - DNS Over HTTPS (doh)
    https://datatracker.ietf.org/wg/doh/charter/
    （doh WG公式ページ）

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

  - KSK Futures (ksk)
    https://datatracker.ietf.org/wg/ksk/charter/
    （KSK Futures BoF公式ページ）

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

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

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