httpbis interim@チューリッヒ レポート
TRANSCRIPT
HTTP/2 これまでの歩み 年 月 トピック
2012年1月 IETF httpbis WGでHTTP/2.0の仕様検討開始することを決定
2012年11月 3つの候補案からSPDY仕様をベースにすることを決定 draft-00(SPDY/3仕様をそのまま)リリース
2013年1月 第1回中間会議(東京) draft-01リリース(HTTPからのUpgrade方法を追加)
2013年4月 draft-02リリース(フレームフォーマット・タイプの大幅な変更)
2013年6月 第2回中間会議(サンフランシスコ) 新ヘッダ圧縮仕様の採用を決定
2013年7月 draft-04リリース(最初の実装ドラフト)
2013年8月 第3回中間会議(ハンブルグ) 最初のHTTP/2.0相互接続試験を実施 draft-06リリース(実装ドラフト)
2013年10月 第4回中間会議(シアトル) 2回目の相互接続試験を実施
2013年12月 draft-09リリース(実装ドラフト)
2014年1月 第5回中間会議(チューリッヒ) 開催
今ココ
第5回 httpbis interim@チューリッヒ 2014 1/22~24
名物チーズフォンデュ
• Cisco Systems がホスト
• 20数名が集まる (F5など新参組も)
• 最終日は TLS WG と Joint (WG chairも参加)
• Application/Security AD達が集まる豪勢なinterim
スイスは 物価高過ぎ!
私は、
ではありませんよ。
HTTP-draft-09/2.0 interop?
僕らスイス来る前に もう済んじゃったから
あらっ!
教訓:宿題はすぐ済ませましょう。
分科会で議論しているから勝手にやっていて
Firefoxのバグ1つ見つけてやったぞ
チューリッヒ interim 概要
• issue の議論と方針決め
• Priority Leveling 仕様の議論 (最後の大物)
• Security Discussion (一応スコープ外で決着)
issue議論の結果 draft10の変更点(見た目編)
• Editorが転職 (MS Open Tech→Mozilla)
• マイナーバージョンの廃止 (HTTP/2, ALPNではh2)
– 2.0←→2.1といった互換通信をしない。
–次は HTTP/3 にすぐ取り掛かる。(短期にバージョンアップ)
• GOAWAY→GTFO(General Termination of Future Operations)
– Google の Hasan と Editor の Martin によるシャレ → 1/29に revert
• FrameType、エラーコード、SETTINGSのリナンバー
– LastCall に向けた準備
• SETTINGSフレーム構造の変更. 5(1+4)バイト毎に
もうチョイ深いdraft10変更点(その1)
• FlowControl停止設定の廃止 –どっちみち DoS対策でフロー制御が必要だよね。
–最大値(31bit)に設定すればいいじゃん。
• DATAフレームにEND_MESSAGEフラグの新設(*) – この後にWebSocketを入れられるようにしようか。
– hybiとジョイント WGをしてWSの検討しよう。
• 負荷分散について記述追加(*) – TCP張りっぱなしだから負荷分散がしにくい
– Alt-Svcヘッダ使って分散する方法の記述を検討
(*) 1/28時点まだ未修整
もうチョイ深いdraft10変更点(その2)
• 拡張(FrameType/SETTINGS)を認めない – DoSの温床、TCP拡張の様にフィルターされるのは嫌だ
– やるなら別ALPN名でやる。
– Google は DNS/Cert. Pushなんかの拡張試験をやるよ。
• TLSの利用条件を厳しく – TLS1.2必須、圧縮不可、 ephemeral cipher suites
(DHE,ECDHE) に制限、エラーコードの新設、BCP参照
• CRIME/BEAST BREACH対策(Padding付加) – BODYはDATAフレームに2種類のPADDINGフラグ(1or2byte)を追加してペイロードの先頭にpaddingを付加。
– HPACKは本当に必要かThreatModel検証が要必要 (*)
(*) 1/28時点まだ未修整
HPACK-06の変更点
• Request/Response の Huffman Tableの共通化(*) – チョット最適化が悪くなるがそれほどでもない
– コンテキストで共通化,サーバプッシュにメリット
• cookie/set-cookie用の Huffman Tableの新設(*) – base64エンコードにして最適化を進めよう
• エンコーダー側からのTableSize指定 – index:0を使おう。reference set消去とかぶるよ(涙)
– FrameHeader Flagじゃあかん。bit flag を変更しようか(*)
– SETTINGS-ACKとは独立。問題があるならエラーに。
• draftはHTTP/2と別々に進めよう。先にセキュリティレビューなどしてもらってもいいし。
(*) 1/28時点まだ未修整
最後の大物 Priority Dependency ユースケースの例 • ダウンロード順が決められてるもの
– jQueryロードしてから、JS実行コード – 分割ビデオやオーディオファイル(1章、2章…)
• DOM Parseに影響するもの – document.write はDOM Parseをブロックするので早く取得
• ユーザ行動 – タブ切り替え、ViewPort変更(優先度変更)
• Server Pushのヒント – 依存性で次にリクエストするファイルが分かるのでプッシュに有用(そもそもサーバ側が情報持っているジャン)
ユーザ視点の高速化に大きく利点、SPDY時代からの課題だが複雑過ぎてGoogleがこれまで取り組めなかった。
Googleの提案 優先度 or ストリームの依存+順番を指定
index.html
a.js
b.js
a.jpg b.jpg
index.html
a.js
b.js
a.jpg b.jpg
END_STREAM
END_STREAM_ACK
dependency list(client) dependency list(server)
Dependency Listを同期
優先度:X 優先度:X
状態の同期は複雑すぎる!
Weighted Dependency Group
0
A
B C
D E
F
G
Priority Group ID: 1234(24bit), Weight: 255(8bit)
ストリーム
Priority Group(24) Weight(8)
X Stream Dependency(31)
• Priority用のGroupを新設 • Group内で0を頂点としたストリーム依存性を定義
• グループ間はWeight比でリソース割り当て
• default はID下24bit, 重み16, stream_id:0に依存
これから議論、検証です。
木構造にしないよ
Security Discussionの前に。 インターネットの脅威
(写真出典 wikipedia) • PRISM: 情報収集・通信監視 • Quantum: バックボーンMITM • Fox Acid: 脆弱性攻撃 • MUSCULAR: データセンター内通信傍受
IESG/IAB要請が出る見込み: IETFの技術仕様は Pervasive Surveillance 対策の検討必須
Security Discussion
• HTTP/2 を TLS に限定する提案
–従来通り HTTP でも利用できるようにする。
• Explicit Proxy(PolicyFilter、VirusScan , etc.用途 )
– HTTP/2のスコープ外にして、継続議論
• http:// の opportunistic(日和見)暗号化
– HTTP/2の進捗に影響ない範囲で検討継続
• コネクション集約
– Client証明書、 subjectAltName対応など問題あり
Security Discussion 結論:HTTP/2 はTLSに限定しない
• HTTP/2は仕様的に、http/https両方使える。
• どう対応するかはマーケットに任せる。
• Firefox/Chrome は httpsのみ、IEは http もサポートするといったちぐはぐが起こる。
ユーザ側のHTTP/2対応に混乱、問題は生じないか?
個人情報を扱うサイトは、HSTS/Key pinning などでフルHTTPS化推進へ
Security Discussion HTTP/2の http:// に日和見暗号を!
• そもそも必要、不要? (このまま何もしないわけにはいかない)
• サーバ認証は? – する(httpsと実質同じ) – しない(Active MITMには無力) – 別の仕組み(DNSSECを使うDANE、TLS拡張を使うTACK等々)
• 切り替え方法は? (対ダウングレードアタック) – ALPNみたいなヒント交換、 DNSレコード、HTTP/2フレーム内で暗号化ハンドシェイク、既存の443ポートを使ってSETTINGSで交換