第19日目の記事です。明日の記事として投稿予定です。106の非技術記事は公開を見送ります。105)の技術記事はこちらです。BoFの続編にあたるBoFです。meetingが開かれました。7858として標準化が行われ、2018年以降は多くのクライアントがDoT・DoHを実装しました。wikiページがあります。Privacyの2つが紹介されました。Villain"と名指しされる事態に発展しました。Domainという仕組みを導入しました。DNS*3からの名前解決がブロックされるか加工されているかを以て該当のネットワーク内にペアレンタルコントロールが存在するかを調べます。...この時点で嫌な予感しかしないというのはそのとおりで、このドメインをブロックするかどうかはエンドユーザーのネットワークよりも先のレベルでも制御できることなので、ある特定のISPでは全域的にcanaryがブロックあるいは加工されてDoHが無効化される、ということもありうるわけです。スライド中にはこの可能性についてテレメトリなどでモニターするとはしていますが、攻撃者が容易に悪用でき本当に想定されるDoHの脅威に対してDoHが使えなくなってしまう危険性があるといえます。参加者の中にはそもそもDNSを用いてペアレンタルコントロールをするべきでない、間違った方法に誘導する仕組みである、という主張も見られました。Port53(Do53)のモデルは、DoHに移行することでローカルネットワークのリゾルバーを無視してパブリックなリゾルバーを全面的に利用するモデルを取ります。Privacyという提案はローカルのDNSリゾルバーの機能を一部借りながらパブリックDNSの機能も利用する、ということでこれらの問題に答えようとします。records(SVCB/HTTPSSVC)というDNSレコードを使って特定の名前のオーナーはこのDoHサーバーを使ってほしいと告知し、ローカルのDNSリゾルバーを使って告知された情報を取得する、としています。ローカルのDNSリゾルバーを併用するモデルを取ることで、ネットワークのローカルポリシーの告知もローカルのDNSリゾルバーが行うことができます。これは特定ネットワークにおけるフィルタリングポリシーの告知の他に、ネットワーク固有の最適化オプションの提示にも使えるとされています*4。最後に、外にも中にも使ってほしいリゾルバーがいる場合どうやってそれを判定するのか?ということについて、リゾルバーの役割ごとに順位付けされたクライアント側のリゾルバー判定アルゴリズムを用意する、としています。DoH*5、直接の名前解決の順に利用できるものを利用します。注目度の高いネタに対して45分枠を設定しただけあってだいぶ議論がヒートアップしていました。Consensus"を求めたい、とchairのスライドにあったことについて、特にこれだけ注目度の高いWGで完全な合意が可能なのか、ということが論争になっていました。surveillance"(プライバシーと監視の問題)があり、DoH/DoTはそもそもそれらと闘うためのものではなかったのか、という声も上がりました。現行のcharter案はこちらから読めます。Resolution"に軽くしか書かなかったanti-DNSSECの側面について書きます。前回のサン・ムーンの感想はこちらです。技術パート非技術記事はこちらです。Resolution】タイトルの通りです。(4)月別アーカイブはてなブログをはじめよう!sylph01さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。