20180223 DNSのトランスポート暗号化に関する調査2018

Slide 1

Slide 1 text

DNSのトランスポート暗号化に関する調査2018 @r_takashima 1 ENOG49 2018-FEB-23 @ 嵐渓荘

Slide 2

Slide 2 text

私と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

Slide 3

Slide 3 text

ENOGとは(おさらい) 3

Slide 4

Slide 4 text

温泉回重要！前回の嵐渓荘（ENOG19,2013) 4

Slide 5

Slide 5 text

本日のお題 • 今回調査の経緯 • 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

Slide 6

Slide 6 text

今回調査の経緯 6

Slide 7

Slide 7 text

2017年9月に IETF doh WG ができた https://datatracker.ietf.org/wg/doh/about/ 7

Slide 8

Slide 8 text

そう言えばGoogle Public DNS にも何か書いてあった https://developers.google.com/speed/public-dns/docs/dns-over-https 8

Slide 9

Slide 9 text

けど、これなんだっけ、調べてみるか、というところから迷走が始まった 9

Slide 10

Slide 10 text

おさらい)DNS のプライバシー問題 ✓DNSSECは返答が「正しいサーバが正しい応答を返したものであるか」は検証できる ✓DNSSECはデータの暗号化を行わなず、クエリ・応答の内容を中間ノードは盗みみる事ができる 10

Slide 11

Slide 11 text

おさらい)DNS のプライバシー問題 cont. ✓DNS QNAME minimization (RFC7816) の様に、クエリの内容を必要最低限にする提案はされている ✓DNS over TLS (RFC7858) や DNS over DTLS (RFC8094) の様にトランスポートにTLSを使う仕様は標準化されているが、イマイチ使われていない(と、思う) 参考：https://dnsprivacy.org/wiki/ 11

Slide 12

Slide 12 text

さて、どうカバーされるのか 12

Slide 13

Slide 13 text

DNS Over HTTPS (doh) 13

Slide 14

Slide 14 text

DNS Queries over HTTPS ✓draft-ietf-doh-dns-over-https-03 が出たばかり 14

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

dohのユースケース ◼ユースケース1 ➢OSやアプリケーション等の DNS クライアントから doh が有効になっているキャッシュDNSサーバへの接続を明示的に設定する OS App キャッシュ DNSサーバ中間ネットワーク 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

dohのユースケース ◼疑問点 ➢クライアント〜キャッシュDNSサーバ間の通信に関しては言及されているが、キャッシュDNSサーバ〜権威DNSサーバ間の通信については？（プロトコル上は問題なく見える） OS App キャッシュ DNSサーバ中間ネットワークインターネット NS of ”.” NS of ”jp.” NS of ”example.jp.” ココは? ？？？ 18

Slide 19

Slide 19 text

dohのプロトコル要求 ◼割と骨子はザックリ ✓HTTPのContent Negotiation を使う ✓HTTP/2のみサポート ◼スコープ外 ✓DNS64 ✓HTTP(not HTTPS) ✓HTTP/1.0, 1.1 19

Slide 20

Slide 20 text

dohの HTTP request ✓media-type は “application/dns-udpwireformat” ➢中身はRFC1035の on-the-wire format そのまま ✓GET と POST をサポート ➢GETは cache friendly だが後述する encode の関係でサイズがでかい 20

Slide 21

Slide 21 text

dohの HTTP request ✓GET では path 内の “dns=“ 以下にクエリが書かれる (*) ➢“dns=“ 以下は base64url で encode ✓POST では body にクエリが書かれる ➢body は encode されない (*)02 時は “body=“だった 21

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

➢同じ人が書いてるI-Dはこちら ✓draft-hoffman-dns-in-json-13 ✓draft-hoffman-simplednsjson-01 (これは 00 でポイされた) dohの HTTP response 26

Slide 27

Slide 27 text

dohの HTTP response ✓DNSとHTTPのCache話 ➢ひとつのAnswer Sectionには複数のRRsetsが入れられる ➢それぞれのRRは個別のTTLが入れられる ➢でも、HTTP response freshness lifetime はセッションで1つなので、DNS RR の一番短い値をいれてあげる必要がある 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

dohの cache ✓DNSとHTTP双方のcacheの仕組みを考慮する必要がある ➢クライアント側では DNS response に含まれるTTL から、 RFC7234 の Age response header を用いた経過時間を差し引いて実際のTTLを検証する ➢いろいろ、書いてあるが具体例に乏しいので省略。要するに HTTP 側での Cache-Control max-age や revalidation ( Last-Modified: みて何かするとか) との関係がややこしい。 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

doh 途中のまとめ ✓HTTPSだと通信が大概できるので DNS over HTTPS ✓今のところフォーカスはクライアント〜キャッシュDNSサーバ間 ✓DNS と HTTP caching の相互作用についてはまだ十分に考慮が進んでいない ✓クライアントが doh ready なキャッシュDNSサーバをどう見つけてどう繋ぐかもまだ決めが足りない 31

Slide 32

Slide 32 text

Google Public DNS の DNS over HTTPS 32

Slide 33

Slide 33 text

https://developers.google.com/speed/pu blic-dns/docs/dns-over-https 33

Slide 34

Slide 34 text

遊び方 ✓https://dns.google.com/resolveで API を叩く ✓https://dns.google.com/query でブラウザから叩く 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

ブラウザアクセスの例 36

Slide 37

Slide 37 text

ん？jsonで返ってくるけど、 ietf-doh だとまだ未定義じゃなかったっけ？ 37

Slide 38

Slide 38 text

そう、Google Public DNS の DNS-over-HTTPS と ietf-doh は別のもの！ 38

Slide 39

Slide 39 text

途中でようやく気付いたぜ orz 39

Slide 40

Slide 40 text

DNS over TLS RFC7858 40

Slide 41

Slide 41 text

✓TCP port 853 をTLSセッションに利用 ✓クライアント〜キャッシュDNSサーバ間での利用を想定 DNS over TLS概要 41

Slide 42

Slide 42 text

✓やっぱり、クライアント〜キャッシュ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

Slide 43

Slide 43 text

おまけ) 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 between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. ✓DPRIVE の scope がそうであれば doh も DNSoTLS も同じか、という感じ https://datatracker.ietf.org/wg/dprive/about/

Slide 44

Slide 44 text

✓いかに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

Slide 45

Slide 45 text

✓そういうの考えてる人もいるらしい。 ✓https://getdnsapi.net/ おまけ) getdns 45

Slide 46

Slide 46 text

✓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

Slide 47

Slide 47 text

✓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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

DNS over DTLS RFC8094 49

Slide 50

Slide 50 text

✓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

Slide 51

Slide 51 text

DNS over dedicated QUIC connections draft-huitema-quic-dnsquic 51

Slide 52

Slide 52 text

✓DNS over TLS の QUIC 版 ✓実験用にはUDP port 784を使うが、正式に IANA から assign されたわけではない ✓スコープはやっぱり、クライアント〜キャッシュDNSサーバ間 DNS over QUIC 52

Slide 53

Slide 53 text

✓PMTUD問題はQUICのレイヤで克服してくれるので DNSoDTLS よりよさそう ✓大きい response も複数ストリームを用いて返せる ✓セッション再利用の問題はQUICにもあるが、QUICはconnection 上で複数のstreamを扱えるので、stream単位でDNSクエリの管理をする事により、connectionをいちいち切ったりしない実装が可能 DNS over QUIC 53

Slide 54

Slide 54 text

まとめ 54

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

完 56