第105回IETF Meeting（モントリオール）報告

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

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

• IETF 104以降のDNS関連RFCの発行状況
  - DNSSECにおけるアルゴリズム実装要件と使用の指針
  
• dnsop WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
• dprive WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
  
• Applications Doing DNS（add）BoFの状況
  
• IEPG会合における話題
  - Path MTU discoveryに対する攻撃
  - DNS Transparency
• 次回のIETF Meetingについて

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

DNSSECにおけるアルゴリズム実装要件と使用の指針

• RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
  （Standards Track、draft-ietf-dnsop-algorithm-update）
  
  RFC 8624は、DNSSECにおけるアルゴリズム実装要件と使用の指針を定義し、既存のRFC 6944を置き換えます[*1]。
  
  RFC 8624では、アルゴリズムの推奨事項が変更され、古いSHA-1を用いたアルゴリズムをMUST NOT（禁止）とし、より安全な方式であるSHA-256[*2]を用いたRSASHA256、楕円曲線暗号[*3]を用いたECDSAP256SHA256への対応をMUST（必須）としています。
  
  また、エドワーズ曲線デジタル署名アルゴリズム（EdDSA）[*4]を用いたED25519をRECOMMENDEDとしています（RECOMMENDEDはSHOULDと同じで、実装しない正当な理由があれば実装しなくても構わないものです）。ED25519は、DNSSECバリデーターにおけるサポートが進んだ後、推奨されるデフォルトアルゴリズムになることが予想されるとしています。
  

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

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

▽DNSにおけるIPフラグメンテーションの回避
（draft-fujiwara-dnsop-avoid-fragmentation）

JPRSの藤原和典が著者として作成している提案で、DNSにおけるIPフラグメンテーション（断片化）[*5]を回避するものです。

現在、DNSではUDPで大きなサイズの応答を返信できるようEDNS0を使用しており、大きなサイズを扱うがゆえにIPフラグメンテーションが起きやすくなっています。最近では、IPフラグメンテーションを悪用した攻撃が問題になっており、攻撃者が断片化された応答やパスMTUディスカバリーに介入する複数の攻撃手法が提示されています。

提案では、DNSでのIPフラグメンテーションを回避する対策として、フルリゾルバー（キャッシュDNSサーバー）のEDNS0リクエスターのUDPペイロードサイズを1220に、権威DNSサーバーのEDNS0レスポンダーの最大ペイロードサイズを1220に指定することとしています。1220を越えた場合、サーバーはTC（切り詰め）ビット[*6]をセットした応答を返し、クライアントはシーケンス番号が確認されるTCPによって再試行することになります。

WGでは、提案内容をサポートする意見が多く挙がったものの、1220を固定値として指定することに対する反対意見もあり、引き続きメ―リングリスト上で議論されていく予定です。

▽複数のDNSSECプロバイダーの併用
（draft-ietf-dnsop-multi-provider-dnssec）

複数のDNSプロバイダーのサービスを用いる環境で、DNSSECを展開する際に生じる課題に対して、適切な展開モデルを紹介する提案です。

一つのDNSプロバイダーしか利用していない場合、障害やDDoS攻撃の程度によっては、名前解決に必要な権威DNSサーバーやそのネットワークがすべて停止してしまう可能性があります。そのため、多くの企業が複数のDNSプロバイダーのサービスを採用しています。しかし複数のDNSプロバイダーを用いる際は、標準ゾーン転送をサポートしない、互換性がなく標準化されていないDNS機能が使用されるといったような課題がある状況です。

提案では、標準ゾーン転送をサポートしない複数のDNSプロバイダーを使用する際のDNSSEC鍵管理方法として、DNSプロバイダーがサポートすべき管理APIの要件を、二つの署名方法のモデルと共に定義しています。

• モデル1：共通KSK、プロバイダーごとに一意のZSK
  - 署名されたDNSKEYリソースレコードセット（以下、RRset）をインポートする方法の提供
  - CDS/CDNSKEYがサポートされている場合、署名されたCDS/CDNSKEY RRsetをインポートする方法の提供
  
• モデル2：プロバイダーごとに一意のKSK及びZSK
  - 外部のDNSプロバイダーからDNSKEY RRsetをインポートする方法の提供
  - CDS/CDNSKEYがサポートされている場合、外部のDNSプロバイダーから個々のCDS/CDNSKEYリソースレコード（以下、RR）をインポートする方法の提供
  

本提案に関しては、レビューを経た後にワーキンググループラストコール（WGLC）が実施される予定です。

▽相互運用可能なサーバークッキー
（draft-sury-toorop-dnsop-server-cookies）

IP Anycastを用いた複数台／複数種類のサーバーを運用する際にも相互運用可能な、DNSクッキー[*7]の作成方法を定義するための提案です。

前回のIETF 104では、DNS実装間の相互運用性を確保するためクッキーを作成するための実装必須かつデフォルトのアルゴリズムとして、SipHash-2.4が指定されました。

今回は、提案の方式を各種実装でテストした際の問題点を踏まえ、RFC 7873のAppendixで定義されている、クライアント／サーバークッキーアルゴリズムの例が変更されました。

提案では、アルゴリズムはSipHash-2.4の1種類のみとなり、クッキー中のCookie algo Sub-Fieldは削除され、Timestamp Sub-FieldとHash Sub-Fieldの利用方法が明確化されました。また、IANAレジストリの作成が要求され、クッキーの作成に用いられるServer Secretのアップデート方法に言及されています。

提案にはBINDやNSDの実装者が参加しており、標準化が進むことが見込まれています。

▽DNS用語集の更新
（draft-hoffman-dns-terminology-ter）

DNS用語集であるRFC 8499[*8]に、用語を追加する提案です。

トランスポートにかかわる用語を中心に、「DNS-over-TLS (DoT)」「DNS-over-HTTPS (DoH)」といった最近の用語を明確にするとともに、DNSのトランスポートとしてUDPもしくはTCPが用いられる従来のDNSを「Classic DNS」と定義しています。

▽HTTPSSVCリソースレコードの提案
（draft-nygren-httpbis-httpssvc）

GoogleのBen Schwartz氏から、Encrypted SNI（TLS 1.3におけるServer Name Indicationの暗号化）やトランスポートプロトコル情報（HTTP/2、HTTP/3（QUIC））などを指定する、HTTPSSVC RRが提案されました。

A/AAAA情報を入れることも可能であるためANAME RR[*9]が不要となる可能性がある一方、HTTPSSVCが非常に大きなRRになる可能性や、ブラウザーでの実装が進みにくいなどの課題認識が共有されました。

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

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

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

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

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

▽TLS上のゾーン転送
（draft-hzpa-dprive-xfr-over-tls）

DoTは、本来スタブリゾルバーとフルリゾルバー間の通信におけるプライバシー確保のためのプロトコルです。本提案は、ゾーン転送もTLS上とすることで、権威DNSサーバー間の通信におけるプライバシーを確保するものです。

Unbound 1.9.2には、既にTCPの代わりにAXFR-over-TLSを実行するオプションが含まれるなど、小さな拡張であるため検討と実装が進むことが期待されます。一方、従来のTCPによるゾーン転送がTCPセッションは一つのゾーン転送にのみ使用する必要があることと同様に、TCP/TLS接続でも一つのゾーンのみという制約によるパフォーマンスの課題があります。そのため、ゾーン同期機構そのものを改善した提案もありました（draft-zatda-dprive-xfr-using-dso）。

DoHはプロトコル仕様がRFC 8484として標準化されましたが、その運用・利用についてはまだ議論が不十分な状態であり、さまざまな懸念が指摘されています。add BoFは、前回IETF 104で開催された「Various issues raised in the DoH context」Side Meeting[*10]で行われた議論を継続するものです。

前回のSide Meetingでは結論が出ていない状況であり、議論を継続するためADD（DNSを実行するアプリケーション）メーリングリストが2019年4月に用意され、そこで行われた議論や新たなトピックについて議論を進めるadd BoFが開催されました。

BoFでは、主にDoT、DoHと従来のDNS（Classic DNS）のアプリケーションでの使いわけや設定などの議論が行われました。ポリシーにかかわる問題でありさまざまな意見が出されましたが、個人のプライバシーを守る立場は共通していました。

DoHはアプリケーションごとに設定が異なる問題点や、適切なサーバー情報を得る方法など議論することが多いため、WGの設置を求める声が多く挙がりました。

アーキテクチャの問題である、ART AreaでなくOPS AreaにWGを作るべきである、dnsop WGで扱うべきであるなど意見が多数出て結局集約されるには至らず、エリアディレクター（AD）間で方向性を議論することになりました。

IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って開催される会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。

Path MTU discoveryに対する攻撃

先述した「DNSにおけるIPフラグメンテーションの回避」の解説として、JPRSの藤原和典がpath MTU discoveryへの攻撃が複数のOSで可能であることを紹介しました。

これに対してConnected UDPならTCPと同じチェックができるというコメントと、Known TSIG keyを用いるTSIG方式の提案がありました。

DNS Transparency

ドメイン名ハイジャック対策として、レジストリの登録情報の書き換え状況を外部のログサーバーに登録・公開しようという、サーバー証明書におけるCT（Certificate Transparency）[*11]と同様の仕組みの提案がありました。

DNSのデータ更新をする際に監視システムにもデータを送り、そこを監視することで、意図せぬデータの変更が入ることを見つけ出す提案です[*12]。異常時は、アラートやセキュリティプロバイダーへの報告により対策が取られることが想定されています。

ドメイン名のレジストリが監視システムへ情報を送る必要がある点は、サーバー証明書におけるCTと同様であり、一元的に対応が可能となるもののレジストリがサポートすることが必要となります。

次回の第106回IETF Meeting（IETF 106）は2019年11月16日から22日にかけ、シンガポールで開催されます。

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