第104回IETF Meeting（プラハ）報告

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の内容は以下の通りです。

なお、期間中に発行された、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メッセージの構文を定義します。

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

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

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

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

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

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

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

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

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

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

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

本提案では、EDNS0を用いてエラーコードを拡張するための「Extended DNSError (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は使われているアルゴリズムが新しいものに置き換わったため、禁止とされています。

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

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

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

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

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

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

本提案では、以下の三つの方法を定義しています。
- HTTPS経由で、DoHサーバーのURIを得る
- DNS経由で、DoHサーバーのURIを得る
- DNS経由で、DoHサーバーのIPアドレスを得る

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

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などのプライバシーポリシーが比較され、議論が行われました。

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

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

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

「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氏の呼び掛けにより開催されました。

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

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

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

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