メールマガジン「FROM JPRS」
バックナンバー：vol.185

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2019/08/29━
                    ◆ FROM JPRS 増刊号 vol.185 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
               第105回IETF Meeting（モントリオール）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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の発行状況

前回の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バリデーターにおけるサポートが進んだ後、推奨され
    るデフォルトアルゴリズムになることが予想されるとしています。

[*1] 提案された背景とその目的の詳細については、過去のドメイン名関連会
     議報告をご参照ください。
     https://jprs.jp/related-info/event/2019/0423IETF.html

[*2] デジタル署名に使われる、代表的なハッシュ関数の一つ。

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

[*4] 高効率、かつ他の署名アルゴリズムで顕在化した問題点を回避する形で
     設計されたデジタル署名方式。

■dnsop WGにおける話題

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

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

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

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

[*5] IPフラグメンテーションの詳細は、JPRS用語辞典をご参照ください。
     https://jprs.jp/glossary/index.php?ID=0180

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

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

[*6] TCビットの詳細は、JPRS用語辞典をご参照ください。
     https://jprs.jp/glossary/index.php?ID=0204

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]の作成方法を定義するための提案です。

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

前回の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]に、用語を追加する提案です。

[*8] RFC 8499についての詳細は、過去のドメイン名関連会議報告をご参照くだ
     さい。
     https://jprs.jp/related-info/event/2018/1213IETF.html

トランスポートにかかわる用語を中心に、「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になる可能性や、ブラウザーでの実装が
進みにくいなどの課題認識が共有されました。

[*9] ANAME RRについての詳細は、過去のドメイン名関連会議報告をご参照くだ
     さい。
     https://jprs.jp/related-info/event/2018/1213IETF.html

■dprive WGにおける話題

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）。

■Applications Doing DNS（add）BoFの状況

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

[*10] 「Various issues raised in the DoH context」Side Meetingの詳細は、
      過去のドメイン名関連会議報告をご参照ください。
      https://jprs.jp/related-info/event/2019/0423IETF.html

前回の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会合における話題

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]と同様の仕組みの提案がありました。

[*11] サーバー証明書におけるCTの詳細は、JPRS用語辞典をご参照ください。
      https://jprs.jp/glossary/index.php?ID=0235

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

[*12] 2019年6月24日に開催された第65回ICANN会合のDNSSEC WorkShop Part I
      にて、同じ提案が行われています。
      https://65.schedule.icann.org/meetings/1058207

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

■次回のIETF Meetingについて

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

          ◇                     ◇                     ◇

◎関連URI

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

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

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

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

  - Applications Doing DNS (add)
    https://datatracker.ietf.org/wg/add/charter/
    （Applications Doing DNS BoF公式ページ）

  - IEPG Meeting - March 2019
    https://iepg.org/2019-07-21-ietf105/
    （IEPG Meeting - July 2019 @ IETF 105公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.