1.
httpbis interim@チューリッヒ
レポート
IIJ 大津 繁樹
2014年１月２８日
HTTP2勉強会#3

2.
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回中間会議(チューリッヒ) 開催
今ココ

3.
第５回 httpbis interim@チューリッヒ
2014 1/22～24
スイスは
物価高過ぎ！
名物チーズ
フォンデュ
私は、
•
•
•
•
Cisco Systems がホスト
ではありませんよ。
２０数名が集まる (F5など新参組も)
最終日は TLS WG と Joint (WG chairも参加）
Application/Security AD達が集まる豪勢なinterim

4.
HTTP-draft-09/2.0 interop?
僕らスイス来る前に
もう済んじゃったから
あらっ！
分科会で議論している
から勝手にやっていて
Firefoxのバグ１つ
見つけてやったぞ
教訓：宿題はすぐ済ませましょう。

5.
現状を一言で表すと、
HTTP/2は第４コーナーに入りました！
でもまだコーナー抜けてません。
最終かどうかも？？？

6.
チューリッヒ interim 概要
• issue の議論と方針決め
• Priority Leveling 仕様の議論 （最後の大物）
• Security Discussion （一応スコープ外で決着）

7.
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)バイト毎に

8.
もうチョイ深いdraft10変更点（その１）
• FlowControl停止設定の廃止
– どっちみち DoS対策でフロー制御が必要だよね。
– 最大値(31bit)に設定すればいいじゃん。
• DATAフレームにEND_MESSAGEフラグの新設(*)
– この後にWebSocketを入れられるようにしようか。
– hybiとジョイント WGをしてＷＳの検討しよう。
• 負荷分散について記述追加(*)
– ＴＣＰ張りっぱなしだから負荷分散がしにくい
– Alt-Svcヘッダ使って分散する方法の記述を検討
(*) 1/28時点まだ未修整

9.
もうチョイ深いdraft10変更点（その２）
• 拡張(FrameType/SETTINGS)を認めない
– DoSの温床、TCP拡張の様にフィルターされるのは嫌だ
– やるなら別ALPN名でやる。
– Google は DNS/Cert. Pushなんかの拡張試験をやるよ。
• TLSの利用条件を厳しく
– TLS1.2必須、圧縮不可、 ephemeral cipher suites
(DHE,ECDHE) に制限、エラーコードの新設、BCP参照
• CRIME/BEAST BREACH対策(Padding付加）
– BODYはDATAフレームに２種類のPADDINGフラグ
（1or2byte)を追加してペイロードの先頭にpaddingを付加。
– HPACKは本当に必要かThreatModel検証が要必要 (*)
(*) 1/28時点まだ未修整

10.
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時点まだ未修整

11.
最後の大物 Priority Dependency
ユースケースの例
• ダウンロード順が決められてるもの
– jQueryロードしてから、JS実行コード
– 分割ビデオやオーディオファイル（１章、２章…）
• DOM Parseに影響するもの
– document.write はDOM Parseをブロックするので早く取得
• ユーザ行動
– タブ切り替え、ViewPort変更（優先度変更）
• Server Pushのヒント
– 依存性で次にリクエストするファイルが分かるのでプッ
シュに有用（そもそもサーバ側が情報持っているジャン）
ユーザ視点の高速化に大きく利点、SPDY時代からの課題だが
複雑過ぎてGoogleがこれまで取り組めなかった。

12.
Googleの提案
優先度 or ストリームの依存+順番を指定
END_STREAM
Dependency Listを同期
END_STREAM_ACK
index.html
状態の同期は
複雑すぎる！
a.js
優先度：X
a.js
b.js
b.js
a.jpg
index.html
優先度：X
b.jpg
dependency list(client)
a.jpg
b.jpg
dependency list(server)

13.
Weighted Dependency Group
Priority Group
ID: 1234(24bit), Weight: 255(8bit)
X
0
A
F
B
C
D
E
G
木構造に
しないよ
ストリーム
Priority Group(24)
Weight(8)
Stream Dependency(31)
• Priority用のGroupを新設
• Group内で0を頂点としたスト
リーム依存性を定義
• グループ間はWeight比でリ
ソース割り当て
• default はID下24bit, 重み16,
stream_id:0に依存
これから議論、検証です。

14.
Security Discussionの前に。
インターネットの脅威
•
•
•
•
PRISM： 情報収集・通信監視 (写真出典 wikipedia)
Quantum： バックボーンMITM
Fox Acid： 脆弱性攻撃
MUSCULAR： データセンター内通信傍受
IESG/IAB要請が出る見込み：
IETFの技術仕様は Pervasive Surveillance 対策の検討必須

15.
Security Discussion
• HTTP/2 を TLS に限定する提案
– 従来通り HTTP でも利用できるようにする。
• Explicit Proxy(PolicyFilter、VirusScan , etc.用途 )
– HTTP/2のスコープ外にして、継続議論
• http:// の opportunistic(日和見）暗号化
– HTTP/2の進捗に影響ない範囲で検討継続
• コネクション集約
– Client証明書、 subjectAltName対応など問題あり

16.
Security Discussion
結論：HTTP/2 はTLSに限定しない
• HTTP/2は仕様的に、http/https両方使える。
• どう対応するかはマーケットに任せる。
• Firefox/Chrome は httpsのみ、IEは http もサポー
トするといったちぐはぐが起こる。
ユーザ側のHTTP/2対応に混乱、問題は生じない
か？
個人情報を扱うサイトは、HSTS/Key pinning などで
フルHTTPS化推進へ

17.
Security Discussion
HTTP/2の http:// に日和見暗号を！
• そもそも必要、不要？ （このまま何もしないわけにはい
かない）
• サーバ認証は？
– する(httpsと実質同じ）
– しない（Active MITMには無力)
– 別の仕組み(DNSSECを使うDANE、TLS拡張を使うTACK
等々）
• 切り替え方法は？ （対ダウングレードアタック）
– ALPNみたいなヒント交換、 DNSレコード、HTTP/2フ
レーム内で暗号化ハンドシェイク、既存の443ポート
を使ってSETTINGSで交換

18.
今後の予定
• 2/7 （最悪2/14)までに draft10 をリリース
– みんな仕事速い！ほとんど修正済
• IETF London(3/2-7)翌日3/8にhttpbisの非公式
interimを開催(正式な interopはやらない）
• 6月上旬米国東海岸で第６回interimを開催
まだまだあきらめまへん
• 4月 HTTP/2 の WG Last Call
• 8月 IETF Last Call を目指す。