Oblivious DNS over HTTPS (RFC 9230)
本Extra Chapterは技術書典13(2022/9)に合わせて追加されたものです。実際の電子書籍版への追加は追って行います。BOOTHで購入された方はアップデート版をダウンロードできるようになる予定です。
ユーザーのDNSクエリの内訳を知ることはそのユーザーのインターネット上での行動傾向の取得につながるため、ユーザーのDNSクエリの中身が知られることはプライバシーリスクであり、それを避けるためにDNS over HTTPSなどの技術が登場したことはこれまで本編に記述した通りです。暗号化されていない通信を大規模にモニタリングすることは実際に行われており、IETFでは”Pervasive Monitoring is an Attack”(広範囲なモニタリング行為はインターネットへの攻撃である)ということをRFCの形式で宣言し、以降のIETFの提案するプロトコルはこのような行為に対する対策を織り込んだ上で設計されるべき、という指針を出しました。DNS over TLS, DNS over HTTPSなどの通信そのものの暗号化により暗号化されていない通信へのモニタリングへの対策は実現されましたが、フルリゾルバーがユーザーの情報を収集するケースはこの場合でも存在します。フルリゾルバーはクエリを行ったユーザーの接続元IPアドレスとクエリの中身を知ることができます。これはホップ間の通信が暗号化されている場合でも同様で、フルリゾルバーがクエリの中身そのものを知らなければクエリを行うことができないからです。
そこで、フルリゾルバーと権威サーバーの両方が「ユーザーのIPアドレス」「クエリの中身」の組を得ることができない方法として、Oblivious DNS、そしてそれをDoHの上で行うOblivious DNS over HTTPSが提案され、そのうちOblivious DNS over HTTPSは2022年6月にExperimental RFCとしてRFC化されました。
RFC化に至る過程
Oblivious DNS (ODNS) はシカゴ大学とプリンストン大学の研究チームによって2019年のPrivacy Enhancing Technologiesという会議にて論文として発表されました。筆者は2019年7月のIETF 105に併設されていたApplied Networking Research Workshop(ANRW) にてその存在を知りました。その後Oblivious DNS over HTTPSは2019年10月に-00版のInternet-Draftが提出されています。2020年12月にはCloudflareが”Improving DNS Privacy with Oblivious DoH in 1.1.1.1”というブログ記事で1.1.1.1でのODoH対応について言及しています。この時点でのドラフトは-03版、最終的に-11版の次でRFCとなっていること、また本RFCの著者の所属はApple, Fastly, Cloudflareであり、AppleもODoHをiCloud Private Relayの一部として実装していることから、かなり実装が先行して作られた仕様であるといえるでしょう。
Oblivious DNSの動作
原理の説明のために元となった実装であるODNSの動作を説明します。ODNSは通常のDNSのプロトコル上で動作するという特徴があり、既存のインフラを維持したままクエリの仕方を工夫するだけでプライバシー上のメリットが得られる、という特徴があります。
- 以下、対称鍵暗号(symmetric encrptyion)と公開鍵暗号(public key encryption) を区別するため、平文を
m
、対称鍵暗号の鍵をsymK
、公開鍵暗号の鍵をpubK
としたとき、前者の暗号文をsymE(symK, m)
、後者の暗号文をpubE(pubK, m)
と表記します。 - クライアントはスタブリゾルバーにドメイン名
dn
について問い合わせたい、とします。- ここで問い合わせるRR typeは通常のDNSクエリと同様任意のものを問い合わせることができますが、簡単のためAレコードを問い合わせたものと思ってください
- ODNS機能を持つスタブリゾルバーは以下の動作を行います。
- セッション鍵
k
を生成する。- このセッション鍵は対称鍵暗号の鍵です
- セッション鍵
k
で問い合わせたいドメイン名を暗号化し、symE(k, dn)
を得ます。 - セッション鍵
k
をODNS権威サーバー(ODNS Authoritative Server)の公開鍵pk
で暗号化し、pubE(pk, k)
を得ます。 - フルリゾルバーに対して、
symE(k, dn)
にTLD.odns
を付与したドメイン名に対するDNSクエリを発行します。- ここでの
.odns
TLDは例示のために用いられているもの(実際には使えないハズ)で、ODNS権威サーバーに対してrecursive queryが発行されるものが設定されます。 - このとき、
pubE(pk, k)
とsymE(k, dn)
の両方をQNAMEフィールドに含めたクエリを発行します。
- ここでの
- セッション鍵
- フルリゾルバーは受け取ったクエリをもとに
.odns
に対して通常のフルリゾルバーの動作通りにDNSクエリを行います。- このとき、フルリゾルバーは接続されたIPアドレスは知っているものの、クエリの中身については暗号化されているため知らないことに注意してください。
- ODNS権威サーバーは以下の動作を行います。
- QNAMEフィールドから
pubE(pk, k)
を取り出し、自身の持つ秘密鍵を使ってセッション鍵k
を取り出します。 - セッション鍵
k
を使ってsymE(k, dn)
からドメイン名dn
を復号し、そのドメイン名に対して通常のDNSと同様のクエリを行い、対応するリソースレコードの値rr
を得ます。 - 得られた
rr
をk
で暗号化しsymE(k, rr)
を得ます。これを応答としてフルリゾルバーに返します。 - なので、ODNS権威サーバーという名前で呼ばれていますが、実質はフルリゾルバーのような振る舞いをしています。
- このとき、ODNS権威サーバーは接続してきたフルリゾルバーのIPアドレスを知ることはできますが、実際のクライアントのIPアドレスを知ることはできません。
- QNAMEフィールドから
- フルリゾルバーは通常のDNSと同様に
symE(k, rr)
をスタブリゾルバーに応答として返します。- ここでもリソースレコードの値は暗号化されているためフルリゾルバーにはわからないことに注意してください。
- スタブリゾルバーはセッション鍵
k
を用いてsymE(k, rr)
からrr
を復元し、クライアントに伝えます。
Oblivious DNS over HTTPSの特徴
Oblivious DNS over HTTPSは上記と同じような動作をしますが、その名前の通りHTTPSを用いてこれを行います。スタブリゾルバーとクライアントの役割がOblivious Client、フルリゾルバーの役割がOblivious Proxy、ODNS権威サーバーの役割がOblivious Targetと呼ばれ、Oblivious ClientはOblivious Targetとの間でセッション鍵を使って暗号化したDNSクエリをやり取りすることでOblivious ProxyがDNSクエリの中身を知ることができないようにしています。
また、Oblivious DNS over HTTPSでは暗号化方式として2022年2月にRFCになったHybrid Public Key Encryption (HPKE) を使っていることも特徴として挙げられます。HPKEの詳細な説明は省略しますが、ODNSの説明で出てきた「セッション鍵を公開鍵暗号で包んで一緒に送る」というよく用いられる方式を整理し今後の拡張に耐えられるようにしたもの、と思っておけばよいと思います。
参考文献、リンク集
- E. Kinnear, et al.”Oblivious DNS over HTTPS (RFC 9230)” https://www.rfc-editor.org/rfc/rfc9230
- P. Mockapetris “Domain Names - Implementation and Specification” https://www.rfc-editor.org/rfc/rfc1035
- 本章においては特に4.1のDNSメッセージフォーマット
- P. Schmitt, et al. “ODNS: Oblivious DNS” https://odns.cs.princeton.edu/
- T. Verma and S. Singanamalla “Improving DNS Privacy with Oblivious DoH in 1.1.1.1” https://blog.cloudflare.com/oblivious-dns/
- “iCloud Private Relay Overview” https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf
- S. Farrell and H. Tschofenig “Pervasive Monitoring Is an Attack” https://www.rfc-editor.org/rfc/rfc7258