DNS暗号化が三つの立場の可視性に与える変化と、残る手がかりによる異常検知の可否
研究計画。DNSを暗号化すると誰が何を見えなくなるのかを三つの立場に分けて測り、その上で異常を見分けられるかを問う
DNS の暗号化を「安全か危険か」の一語で評価するのをやめ、端末、リゾルバ、ネットワークを外から見る者という三つの立場に分けて、誰が何を見えなくなるのかを測る。そのうえで、問い合わせた名前そのものを集めずに、頻度、失敗率、時間の偏りだけから異常を見分けられるかを調べる。前半で作るのは検知器ではなく、privacy と運用可視性の対応表である。後半でその表の上に検知を載せる。本ページは計画であり、実験はまだ行っていない。以下に実測値は無い。
| 方法 | 研究環境で使える標準的な実装を用い、暗号化しない DNS と DoT、DoH、DoQ を比べる。それぞれについて、キャッシュが空のときと温まったとき、短い問い合わせの集中、長時間の利用、リゾルバの切り替えを測る。ネットワークの条件として往復時間とパケットの損失を段階的に変える。個人の実際の問い合わせは収集せず、研究用のドメインと合成した負荷だけを使う。異常の側では、研究用のリゾルバで高頻度、失敗に偏ったもの、周期的な問い合わせといった安全な異常を作り、リゾルバ側でまとめた記録と端末側のメタデータのどちらがどれだけ効くかを、同じデータと同じ分け方で比べる。問い合わせた名前そのものは成果に残さず、必要な場合も分類、ハッシュ、集約にする。 |
|---|---|
| 結果 | 実験前である。本ページに実測値は無い。「予想」として書いたものは検証前の仮説であって、測定の結果ではない。 |
| 知見 | 中心の問いは、暗号化を強めるほど運用可視性が必ず失われるのか、という点にある。もし端末とリゾルバの側に必要最小限の記録を設計できるなら、問い合わせの内容をネットワークへ出さないまま、障害の解析には十分たどり着けるかもしれない。失われるのは可視性そのものではなく、可視性を得る場所が移るだけかもしれない。それを確かめる。 |
| 限界 | 小さなテスト環境と実環境の差。合成した負荷が実際の名前解決のふるまいを代表しているとは限らないこと。実装と版に結果が左右されること。リゾルバの実装ごとの差。正常そのものが時間とともに変わること。記録の欠落と、機器ごとの時計のずれ。研究用に作った異常が未知の異常を代表しているとは限らないこと。研究チームが2名であるため、初めに扱う対象を絞る必要があること。 |
状態：実験前。この記事は研究の目的と方法を先に公開するための記録である。数値はまだ一つも出ていない。以下に「予想」と書いたものはすべて検証前の仮説であり、実測値として扱わない。
「DNSの暗号化は安全か」という問いを捨てる
DNS を暗号化すべきかどうかは、しばしば一語で論じられる。しかしこの問いは、誰にとっての話かを決めないと答えられない。DoH、DoT、DoQ を使うと、問い合わせの内容、接続先、時間の細かさ、どのリゾルバを使っているかが、見える人と見えなくなる人に分かれる。端末の持ち主にとっては守られ、同じ構内のネットワークを見ている運用者にとっては失われる。
そこでこの研究では、最初から三つの立場に分けて扱う。
端末
問い合わせの文脈をすべて持っている。ここでの問いは逆向きで、手元の記録をどこまで減らしても障害の解析ができるかである。
リゾルバ
問い合わせを処理する立場。キャッシュに当たったか、応答の符号、遅延といったものを、まとめた形で扱う。
ネットワークを外から見る者
暗号化された通信の外側だけを見る。復号はしない。ここに何が残るかが、境界で監視している運用者の手札になる。
この三者で見える情報を表にする。表の欄が埋まるか消えるかは、選んだ暗号化の方式で変わる。この研究の前半の成果は、検知器ではなくその表である。
privacy を一つの数字にしない
privacy の強さを一つの得点にまとめると、比べやすくはなるが、何が守られて何が守られていないかが見えなくなる。そこで、次の軸ごとに何が露出するかを書き出す。
- 識別子がどれだけ長く同じままか
- 時刻がどの細かさで残るか
- 場所やネットワークがどの粒度で分かるか
- 相手の分類がどこまで細かいか
- どれだけの期間残るか
この五つは足し合わせない。足し合わせた数字は、どの軸で危ういのかを隠してしまうからである。
性能も、平均で語らない
暗号化すると遅くなる、という言い方も雑すぎる。測るのは次のものである。
- 名前解決にかかる時間の分布（中央値だけでなく、遅いほうから 5% と 1% の値）
- 接続を確立する費用と、接続を使い回せた割合
- キャッシュに当たったときと外れたときの差
- 問い合わせ一件あたりのパケット数とバイト数
- リゾルバが落ちたときのふるまい
- ネットワークが変わった後、元に戻るまでの時間
中央値だけを見ると、暗号化の影響は小さく見えることがある。効いてくるのは遅いほうの端で、そこは往復時間と損失の条件を変えたときに初めて現れる。
その上で、異常を見分けられるか
ここまでが「何が見えるか」の話で、ここからが「見えるもので何ができるか」の話である。問い合わせた名前の文字列を集めないという前提のまま、頻度、失敗率、時間の特性から異常を見分けられるかを調べる。
- 名前の文字列が無くても、頻度・失敗率・時間の特性から一部の異常は出せる。
- 端末単位とリゾルバ集約の両方を使うと成績が上がる。
- privacy のために情報をまとめるほど、精度との間に交換が生じる。
比べるのは、リゾルバ集約だけ、端末メタデータだけ、両方を突き合わせたもの、privacy のために情報を削った組、の四つである。同じデータと同じ分け方を使い、比較の相手どうしで必要のない複雑さの差を作らない。
記録の形
実験 ID、シナリオ ID、時刻、正解ラベル、特徴量、検知器の出力、検知した時刻を最低限持つ形にそろえる。正解は実験を回す側が持ち、検知器には渡さない。結果の表は実験を回す仕組みが出した機械生成の数値から組み立て、文章を書くモデルが測定値を埋めることはしない。言語モデルは標準文書の整理や解析コードの確認には使うが、実験結果の数値の生成には使わない。
メタデータが運ぶのは、量と頻度だけではない
「外から見る者には外形しか残らない」という言い方には、注意がいる。外形が思ったより多くを語る場合があるからである。
Weiss らは、応答を少しずつ送る作りの AI アシスタントについて、暗号化された通信に残る応答の長さの並びから、返答の話題を推定できることを報告した。復号はしていない。残った外形だけを手がかりにしている。
この報告は、本研究にとって二つの意味を持つ。一つは、ネットワークを外から見る者の欄を「何も見えない」と書いてはいけないということ。もう一つは、記録を残す側にとっては、外形の保存それ自体が開示になり得るということである。だから本研究では、外形を保存する場合も集約した値にとどめ、個々の並びをそのまま残さない。
予想（まだ測っていない）
暗号化を強めるほど運用可視性が一律に失われる、という単純な関係にはならないと考えている。失われるのは境界から見る者の可視性であって、端末とリゾルバの側には情報が残っている。もし後者に必要最小限の記録を設計できるなら、問い合わせの内容をネットワークへ出さないまま、障害の解析には十分たどり着けるかもしれない。
異常の検知については、名前の内容を持たなくても一定の異常は識別できる一方、情報を削るほど取りこぼしが増える領域が現れると予想している。目標は最も強い検知器を作ることではなく、安全と privacy の両方について、これ以上どちらかを良くするともう一方が必ず悪くなる境目を描くことである。
この節は仮説である。実験の後に、実測値、図表、区間推定、誤りの分析へ置き換える。
思った通りにならなくても価値がある結果
端末側の記録をどれだけ足しても境界側の取りこぼしが埋まらなかった場合、それは「暗号化した DNS の監視は境界では諦めて、端末側の設計に移すべきだ」という結論になる。逆に、リゾルバの集約だけで十分だった場合は、端末に記録を置く必要がないという結論になる。どちらも、どこに手をかけるべきかを一つ減らしてくれる。
限界
- 小さなテスト環境と実環境の差
- 合成した負荷が、実際の名前解決のふるまいを代表しているとは限らないこと
- リゾルバの実装ごとの差と、ソフトウェアの版への依存
- 正常そのものが時間とともに変わること
- 記録の欠落と、機器ごとの時計のずれ
- 研究用に作った異常が、未知の異常を代表しているとは限らないこと
- 研究チームが2名であるため、初めに扱う対象を絞る必要があること
参考文献
- Hoffman, P., McManus, P. DNS Queries over HTTPS (DoH). RFC 8484, 2018. DOI: 10.17487/RFC8484.
- Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Hoffman, P. Specification for DNS over Transport Layer Security (TLS). RFC 7858, 2016. DOI: 10.17487/RFC7858.
- Huitema, C., Dickinson, S., Mankin, A. DNS over Dedicated QUIC Connections. RFC 9250, 2022. DOI: 10.17487/RFC9250.
- Weiss, R., Ayzenshteyn, D., Amit, G., Mirsky, Y. What Was Your Prompt? A Remote Keylogging Attack on AI Assistants. arXiv:2403.09751, 2024.
- NIST. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management. 2020. DOI: 10.6028/NIST.CSWP.01162020.
- NIST, Trustworthy Intelligent Networks（AI/ML による DNS abuse の検知を研究対象に含む）。
arXiv の一件は査読済み出版物と同等には扱わない。上の書誌は実物を確認した。