HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 (3)

2013/2/8-1

個人的は、それは壮大なゴールだと考えています。しかし、同時にWebセキュリティは他にも様々なところが壊れています。 TLSについて語るのであれば、ファイアウォールや国境や企業や学術機関で利用されている、man in the middle TLSによって、そこを流れる全てのものを見ることが可能になります。それについて知らなかった人は、その話を聞くとビビるのですが、私がいる業界では昔から知られていることです。もっと多くの人々が、そういった現状を知るべきだと思います。

Q: 以前、CAがクラックされたというニュースが流れてましたね

多くの人々が、そのニュースを知りません。 Webブラウザに表示される小さな鍵は、かつて意味していた意味を為していません。そして、それに関しては修正する必要があると考えています。

IETFで、DANE(DNS-based Authentication of Named Entities, http://datatracker.ietf.org/wg/dane/charter/)という取り組みがあります。 DNSSECによるものです。 CAシステムは、複数の様々なベンダーを信用のrootとしますが、それが上手くいかないことは既に知られています。

DNSSECでは、信用のrootはDNSルートです。そして、誰かが「TLSの鍵をDNSに入れたらどうだろうか」というアイデアを思いつきました。暗号情報がWebサイトを識別するというものです。 DNSSECを使って確認し、DNSSECによって署名されていることでドメイン名との関連を知ることが出来ます。証明書そのものがDNSに入っている必要は無いという提案もありますが、それはまだ現在進行中の議論です。

DANEの手法を回避するために、CAをWebブラウザに登録するような手法は使えません。 CAにアクセスがある人が、回避することもできません。

DANEの大きな問題は、デプロイが非常に難しいことです。 DNSSECは、デプロイが非常に難しい技術です。 Webセキュリティに関しては、非常に多くの議論がありますが、個人的にはこれは最も大事な話のひとつだと考えています。

Q: 優先度やフローコントロールに関して言及されていました。それは、HTTP 2.0ではWebサーバ管理者が各コンテンツ毎にプライオリティを設定する必要があるということですか？

それは非常に実装依存な話になります。 httpbisワーキンググループでも、この話は少しだけしています。これは、我々が定義する話ではありませんが、必要に応じて状況を見たいと思います。

非常にシンプルなストラテジは、「最初にJavaScriptとCSSを送り、その他全てはその後送ります」といった方法になるかも知れません。多くのWebブラウザにとって、ページ生成においてそれらが重要であるからです。

サーバによっては、データドリブンなアプローチを取れるかも知れません。色々と興味深いことをその周辺でできそうです。

Akamaiの立場としては、そこは非常に興味深い部分です。自分のネットワークを見つつ、最適化し、継続的に改善するチャンスがあるためです。

Q: HTTP 2.0が普及することによって、Web業界にどのような影響があると考えられますか？たとえば、Webデザインを行っている会社等が新しい技術や設定手法を覚える必要がありますか？

彼らが、そこまで深いところを知る必要が出るようには思えません。そうならないことを願います。

変わる可能性があるのが、HTTP 1.1の挙動に対する各種テクニックやワークアラウンドなどです。たとえば、CSSスプライトというのがあります。こういったHTTP 1.1に対するワークアラウンドを撤廃し、もっと理にかなった設計に注力できるようになります。人々が目にする最も大きな変化は、そこら辺だと思います。

しかし、人々に対するガイダンスは必要になります。 httpbisワーキンググループは、上手く移行するためのドキュメントを書くことにも着目しています。

Webパフォーマンスコミュニティもガイドラインやツールを作るでしょう。もちろん、Akamaiのような企業も顧客を手伝います。

Q: それは、AkamaiのAkamai's Front End Optimizationのようなものですか？

はい。ただし、FEOの動作を確実に変えるでしょう。

どちらかというと、HTTP 2.0の取り組みは、FEOにとって邪魔なものを取り除くような作業です。そして、さらにエキサイティングな取り組みを将来行えるようにするためです。

たとえば、現在の環境でJavaScriptをロードしているときには、Webブラウザがファイル全体をロードするまでJavaScriptのパーシングは開始されません。 Googleは、JavaScriptを細切れにすることによって、より良いユーザエクスペリエンスを実現する興味深いテクニックを実現しました。しかし、それをするには、複数のフレームによって複数のファイルに分ける必要があり、非常に汚い方法と言えます。 Web開発者にとっては悪夢です。

(続く：次へ)

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！