Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DNS privacy of transport layer

587 views

Published on

DNS トランスポートのプライバシーと暗号化の話の 2018/2時点での情報をまとめてみました。

Published in: Internet
  • Be the first to comment

  • Be the first to like this

DNS privacy of transport layer

  1. 1. DNSのトランスポート暗号化 に関する調査2018 @r_takashima 1 ENOG49 2018-FEB-23 @ 嵐渓荘
  2. 2. 私とENOGとちょっとNISOC • ENOG4/OSC新潟2010 • ISP の中の運用とオープンソース【実践編】 (NetFlow,sFlow) • NISOC 2011/2 • 初めてのDNSSEC • ENOG19 • IETF TRILL 最新 update • ENOG27 • Network 装置の White box 化について • ENOG28 • OpenStack Juno で何が入るかみてみよう • ENOG34 • 君のキャッシュDNSサーバが出すクエリを君は本当に理解しているか? あ、でもそのうちそうなっちゃうかも? QNAME minimisation の話 ♨️ ♨️ 2
  3. 3. ENOGとは(おさらい) 3
  4. 4. 温泉回重要! 前回の嵐渓荘(ENOG19,2013) 4
  5. 5. 本日のお題 • 今回調査の経緯 • DNS Queries over HTTPS (ietf-doh) • Google Public DNS の DNS over HTTPS • DNS over TLS (RFC7858) • DNS over DTLS (RFC8094) • DNS over dedicated QUIC connections • まとめ 5
  6. 6. 今回調査の経緯 6
  7. 7. 2017年9月に IETF doh WG ができた https://datatracker.ietf.org/wg/doh/about/ 7
  8. 8. そう言えばGoogle Public DNS にも 何か書いてあった https://developers.google.com/speed/public-dns/docs/dns-over-https 8
  9. 9. けど、これなんだっけ、 調べてみるか、 というところから迷走が始まった 9
  10. 10. おさらい)DNS のプライバシー問題 DNSSECは返答が 「正しいサーバが正しい応答を返したものであるか」 は検証できる DNSSECはデータの暗号化を行わなず、 クエリ・応答の内容を中 間ノードは盗みみる事ができる 10
  11. 11. おさらい)DNS のプライバシー問題 cont. DNS QNAME minimization (RFC7816) の様に、クエリの内容を必要最低限 にする提案はされている DNS over TLS (RFC7858) や DNS over DTLS (RFC8094) の様にトランスポートに TLSを使う仕様は標準化されているが、イマイチ使われていない (と、思う) 参考:https://dnsprivacy.org/wiki/ 11
  12. 12. さて、どうカバーされるのか 12
  13. 13. DNS Over HTTPS (doh) 13
  14. 14. DNS Queries over HTTPS draft-ietf-doh-dns-over-https-03 が出たばかり 14
  15. 15. dohの狙い End-to-end の通信を暗号化する事により、DNS通信におけるプライ バシー問題を解決すること DNSの通信はしばしば end-to-end の接続性に問題が生じるが、 HTTPS なら大概通る ここらへんの記述に後述のDNSoTLSとか使われ辛いんだろう なぁという悩みを感じる DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. 15
  16. 16. dohのユースケース ユースケース1 OSやアプリケーション等の DNS クライアントから doh が有効 になっているキャッシュDNSサーバへの接続を明示的に設定 する OS App キャッシュDNS サーバ 中間ネットワーク 16
  17. 17. dohのユースケース ユースケース2 Web App にCORSを使ってDNS情報を参照させる。ブラウザ側は dohを利用しようとするWeb App以外にはその参照結果は流用し ない。 オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、追加 の HTTP ヘッダを使用して、ユーザーエージェントが現在のサイトとは別の オリジン(ドメイン)のサーバーから選択されたリソースにアクセスする権限 を得られるようにする仕組みです。ユーザーエージェントは、現在の文書のオ リジンとは異なるドメイン、プロトコル、ポート番号からリソースをリクエス トするとき、オリジン間 HTTP リクエストを発行します。 https://developer.mozilla.org/ja/docs/Web/HTTP/HTTP_access_control CORS 17
  18. 18. dohのユースケース 疑問点 クライアント〜キャッシュDNSサーバ間の通信に関しては言 及されているが、キャッシュDNSサーバ〜権威DNSサーバ間の 通信については?(プロトコル上は問題なく見える) OS App キャッシュDNS サーバ 中間ネットワークインターネット NS of ”.” NS of ”jp.” NS of ”example.jp.” ココは? ? ? ? 18
  19. 19. dohのプロトコル要求 割と骨子はザックリ HTTPのContent Negotiation を使う HTTP/2のみサポート スコープ外 DNS64 HTTP(not HTTPS) HTTP/1.0, 1.1 19
  20. 20. dohの HTTP request media-type は “application/dns-udpwireformat” 中身はRFC1035の on-the-wire format そのまま GET と POST をサポート GETは cache friendly だが後述する encode の関係でサイズがでかい 20
  21. 21. dohの HTTP request GET では path 内の “dns=“ 以下にクエリが書かれる (*) “dns=“ 以下は base64url で encode POST では body にクエリが書かれる body は encode されない (*)02 時は “body=“だった 21
  22. 22. dohの HTTP request GETの sample ( I-D 03 より抜粋 ) :method = GET :scheme = https :authority = dnsserver.example.net :path = /dns-query?ct& (no space or CR) dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB accept = application/dns-udpwireformat, application/simpledns+json 22
  23. 23. dohの HTTP request POSTの sample ( I-D 03 より抜粋 ) :method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-udpwireformat,application/simpledns+json content-type = application/dns-udpwireformat content-length = 33 <33 bytes represented by the following hex encoding> 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 23
  24. 24. dohの HTTP request 投げ先のURI 02まではこう書いてありましたが 03でこうなりました Configuration and discovery of the URI is done out of band from this protocol. A client can be configured with a DNS API URI, or it can discover the URI. This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI. 24
  25. 25. dohの HTTP response DNS response は HTTP responseの body に入る (当然といえば当然) “the response types are works in progress” “application/dns-udpwireformat” が使えることは確定 json based のもあったほうがいいよね、とはあるが、未定 サンプルにある”application/simpledns+json” も規定されているわけで はなくただの yet another media-type の例 25
  26. 26. 同じ人が書いてるI-Dはこちら draft-hoffman-dns-in-json-13 draft-hoffman-simplednsjson-01 (これは 00 でポイされた) dohの HTTP response 26
  27. 27. dohの HTTP response DNSとHTTPのCache話 ひとつのAnswer Sectionには複数のRRsetsが入れられる それぞれのRRは個別のTTLが入れられる でも、HTTP response freshness lifetime はセッションで1つなので、DNS RR の一番短い値をいれてあげる必要がある 27
  28. 28. dohの HTTP response POSTの sample ( I-D 03 より抜粋 ) www.example.comのAが192.0.2.1でTTLが128の場合 :status = 200 content-type = application/dns-udpwireformat content-length = 64 cache-control = max-age=128 <64 bytes represented by the following hex encoding> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 28
  29. 29. dohの cache DNSとHTTP双方のcacheの仕組みを考慮する必要がある クライアント側では DNS response に含まれるTTL から、RFC7234 の Age response header を用いた経過時間を差し引いて実際のTTLを検証 する いろいろ、書いてあるが具体例に乏しいので省略。 要するに HTTP 側での Cache-Control max-age や revalidation ( Last-Modified: みて 何かするとか) との関係がややこしい。 29
  30. 30. doh server の discovery まだ出来てない。ここの認証も考えないと意味ない気がする。 [[ From the WG charter: The working group may define mechanisms for discovery of DOH servers similar to existing mechanisms for discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus. ]] 30
  31. 31. doh 途中のまとめ HTTPSだと通信が大概できるので DNS over HTTPS 今のところフォーカスはクライアント〜キャッシュDNSサーバ間 DNS と HTTP caching の相互作用についてはまだ十分に考慮が進んでい ない クライアントが doh ready なキャッシュDNSサーバをどう見つけてど う繋ぐかもまだ決めが足りない 31
  32. 32. Google Public DNS の DNS over HTTPS 32
  33. 33. https://developers.google.com/speed/public -dns/docs/dns-over-https 33
  34. 34. 遊び方 https://dns.google.com/resolveで API を叩く https://dns.google.com/query でブラウザから叩く 34
  35. 35. xavier:~$ curl -s 'https://dns.google.com/resolve?name=www.hanya-n.org&type=A' | jq { "Status": 0, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "www.hanya-n.org.", "type": 1 } ], "Answer": [ { "name": "www.hanya-n.org.", "type": 5, "TTL": 21599, "data": "urquell.hanya-n.org." }, { "name": "urquell.hanya-n.org.", "type": 1, "TTL": 21599, "data": "49.212.140.172" } ], "Comment": "Response from 49.212.140.172." } API ア ク セ ス の 例 35
  36. 36. ブラウザアクセスの例 36
  37. 37. ん?jsonで返ってくるけど、 ietf-doh だと まだ未定義じゃなかったっけ? 37
  38. 38. そう、Google Public DNS の DNS-over-HTTPS と ietf-doh は別のもの! 38
  39. 39. 途中でようやく気付いたぜ orz 39
  40. 40. DNS over TLS RFC7858 40
  41. 41. TCP port 853 をTLSセッションに利用 クライアント〜キャッシュDNSサーバ間での利用を想定 DNS over TLS概要 41
  42. 42. やっぱり、クライアント〜キャッシュDNSサーバ間 明示的にキャッシュDNSサーバ〜権威DNSサーバ間は out of scope と記 述 DPRIVE の scope がそうであれば doh も同じか・・・ DNS over TLSのスコープ The protocol described here works for queries and responses between stub clients and recursive servers. It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter. 42
  43. 43. おまけ) DNS PRIVE WG のチャーター 43 The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality DPRIVE の scope がそうであれば doh も DNSoTLS も同じか、という感 じ https://datatracker.ietf.org/wg/dprive/about/
  44. 44. いかにTLSセッションを確立する際のコストを減らすかだがコレ。 張ったセッションのライフサイクル管理を含むレゾルバライブラリ の実装を考慮しなくちゃいけない、よね。。 TLS のセッション確立コスト問題 For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and close TCP connections for each DNS query. 44
  45. 45. そういうの考えてる人もいるらしい。 https://getdnsapi.net/ おまけ) getdns 45
  46. 46. DNSoTLS enabled なキャッシュDNSサーバをクライアントはどの様に選 定するか 予め Out-of-bound で Privacy Profile を持っておくやり方と、DHCP 等で緩 く渡すやり方がある 認証単体でもいろいろと議論があるようなので興味がある人は • https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ DNS over TLS の認証 46
  47. 47. TLS確立時間を含むレイテンシ TLS/TCPのセッション管理 TLSの暗号処理コスト 同時接続数(クライアントの数) 等、考慮事項はあるが だそうです。 DNS over TLS の性能問題 A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS over TLS (and DNS over TCP) is discussed in [TDNS] and [RFC7766]. 47
  48. 48. Quad9 ( https://www.quad9.net/ , 9.9.9.9 ) は DNSoTLS もサポートしてるらしいよ! 遊び方 https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security 48
  49. 49. DNS over DTLS RFC8094 49
  50. 50. TLSはTCP、DTLSはUDP UDP port 853 を利用 PMTUD問題がつきまとう まじかー。。。 DNS over DTLS DNS over DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations, the DNS server will respond with a truncated response (see Section 5). 50
  51. 51. DNS over dedicated QUIC connections draft-huitema-quic-dnsquic 51
  52. 52. DNS over TLS の QUIC 版 実験用にはUDP port 784を使うが、正式に IANA から assign されたわけで はない スコープはやっぱり、クライアント〜キャッシュDNSサーバ間 DNS over QUIC 52
  53. 53. PMTUD問題はQUICのレイヤで克服してくれるので DNSoDTLS よりよさ そう 大きい response も複数ストリームを用いて返せる セッション再利用の問題はQUICにもあるが、QUICはconnection上で複 数のstreamを扱えるので、stream単位でDNSクエリの管理をする事によ り、connectionをいちいち切ったりしない実装が可能 DNS over QUIC 53
  54. 54. まとめ 54
  55. 55. IETF DPRIVE WG の範疇 クライアント 〜キャッシュDNSサーバ間がスコープ DNSoTLS (RFC7858)  TCP853  TLSで保護  セッション利用の効率 化等の考慮が必要  proposed standard DNSoDTLS (RFC8094)  UDP853  PMTUD、fragment の 問題がある  experimental IETF DNSoHTTPS  HTTPSだから通りやす い  WG draft IETF DNSoQUIC  QUICだから通りやすい  connection/streamの階 層がDNSに良さげ  Individual draft Google Public DNS DNS-over-HTTPS  名前は同じだが、IETF I-Dのと関係なし  jsonで返答 UDP版 HTTPS版QUIC版 無関係! ❌ 55
  56. 56. 完 56

×