httpbis WG IETF89レポート

https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.
IETF89 報告
株式会社レピダム
前田薫 (@mad_p)
http2 勉強会 #4 2014/03/20

Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF89概要
 ロンドン 2014/3/2～3/7
 httpbis WG 3/3, 3/5

draft-10, hpack-06
 2月に出た
 前回 (1月Interim報告)からの変更
 GOAWAY → GTFO キャンセル
 DATA, HEADERS, PUSH_PROMISE, CONTINUATION
フレームにPadding
 用途については後述
 END_MESSAGE → END_SEGMENT
 cookie用のHuffmanテーブル → キャンセル

WGのトピック
 Local Activity report (Jack + Hiro)
 実装、ドラフト、ALPNなど進捗
 issuesの議論
 Group Priority
 HPACK脆弱性
 Alt-Svc

issuesの議論
 #419 Settingsフレームは空でもよいことを明示
 HTTP/1.1からのアップグレード時のみ
SETTINGS_MAX_CONCURRENT_STREAMS
SETTINGS_INITIAL_WINDOW_SIZE が必須だったのも不要に
 #405 Server Authority と Same-Origin → HTTP/1.1に
合わせる
 #404 クライアントはgzip, deflate両方のサポートが
MUSTか? → gzipのみ

issues続き
 #386 Websocketサポート
 draft-hirano-websocket-over-http2
 :schemにサポート外スキームを指定された場合は?
 → streamエラー → コード新設
 #365 Header Table Emptyingが2バイトでもったいな
い件 → static table + 1 など検討されたが、no action
 #386 DNS SRV → http/2とは切り離す。実験/議論が
必要

Priority Leveling
 Groupベース
 Priority → 0と255を特別という案
 Dependencyベース
 新レベルのinsertに問題 → inserフラグ
 どっちの戦略? 複雑すぎるのでは?
 → プロトコルが正しいかどうかではなく性能に関
わる話である
 → 複雑さはサーバー側、クライアントはシンプル
 ユースケースがもっと必要
 http/2に入らなければhttp/3に入れてもいい

HPACK脆弱性
 http2ハッカソン #1で議論したとおり
 ヘッダ圧縮率がオラクルとして働く
 低エントロピーでなければあまりコワクない
 クッキーはエントロピー高いがパスワードは?
 センシティブなヘッダは圧縮しない案
 ホワイトリスト方式かブラックリスト方式を議論
 圧縮するなフラグを用意(個別設定)で合意、セキュリ
ティ考察も追加
 却下された案
 MAX_CONCURRENT_STREAMを小さくすれば試行が少な
くなるという案、一定回数の失敗で忘れる案、一定確
率で圧縮しない案

designer meeting 3/8
 Mozilla Londonオフィスで開催
 Preliminary Minutes

designer meetingトピック
 issue検討続き
 Padding
 HPACK
 SRV/DNS
 Alt-Svc
 Priority Leveling →
 Proxy

issues続き
 #363 TLS renegotiations
 TLS接続後に特定URLでクライアント証明書を要求する場合が
ある。firefoxでは同一connectionでTLSネゴシエーションをや
り直す
 HTTP/2ではすでにこのconnectionで他のstreamが走っている
かもしれない
 → renegotiationを許さない方向で議論を続ける
 #362 BLOCKED frame提案
 フローコントロールのためブロックされていることを相手に
伝える
 デバッグも難しいしinteropもつらい
 この仕様が必要かどうかで長い議論
 → MLで議論継続

Padding
 フレーム側の仕組としてPaddingを設ける
 HPACK側はpaddingなし
 flow-controlにどう影響するの? など議論
 BREACH/CRIMEアタックに対しては、観測結
果が確率的にしか得られないことで緩和
 ドラフト10ではPaddingによる攻撃への効果は限
定的であることも言及している

HPACK
 ハフマンでのEOS
 paddingしないならEOS必要ないよね
 →でも後でまたpaddingしようと思ったらそのとき必要になるよね?
 → どうでもいい派が多数。興味ある人がランチ中に議論
 クッキーだけ別テーブル(base64)という案は?
 十分なinterestがなかった → 廃案
 Kazuの指摘があるけれどStaticだけではダメか?
 長い時間かかってgzip並の圧縮率になったわけで、データに基づいた結果
だよ
 → そのデータある? → いやもうない
 Robertoとの個人的な会話: HPACK効率を測るためのデータセットがほ
しいよね
 feedback loopに注意。HPACKを修正する → 送信されるデータが変わる →
最適なパラメータも変わる
 server-pushについては、実装がない → いまデータがない

SRV/DNS
 http/1.1を話すことなく、エンドポイントが
http/2を話すかどうか知りたい → DNSのSRV
レコードでできないかという案
 仕様化するには未成熟
 Alt-Svcとうまく合わなければならない
 → 文書を作る

Alt-Svc (Alternative Service)
 http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03
 同一のサービスが他のエンドポイントでも
提供されることを示す仕組み
 サーバーからクライアントに、プロトコル、ホ
スト、ポートを教える
 HTTP/1.1レスポンスヘッダ Alt-Svc
 Alt-Svc: "h2"=8000, "h2t"=443
 HTTP/2 ALTSVC frame

Alt-Svcのユースケース
 HTTP/1.1 からのアップグレード
 #315 http:// スキームだけどTLS使いたい
 #349 Load Asymmetry(ロードバランシング)
 他のポートへリダイレクト
 SNI (TLS Server Name Indication)未対応クライ
アントの隔離
 Alt-Svcを理解するならSNIもわかるだろう → 高
性能サーバーへリダイレクト

Alt-Svc関連issues
 #315 http:// over TLS
 プロキシまでHTTP/TCPで行き、プロキシからサー
バーまでをTLSで行くことを許すか
 http2にしたいが「:scheme」ヘッダはHTTP/1.1にはない
 サーバーから見ればアタックに見える
 end-2-endでTLSになった後httpアクセス行ったらどうか?
 #421 mixed scheme → 明示的許可を記述
 #426 unsupported scheme → エラー新設
 payload semantics
 draft-ietf-httpbis-p2-semantics-26
 http2エラーコードとhttpステータスコードの関係

Proxy
 長ーい議論があって正直追いつけなかった
 proxies: HTTP2ではHTTP/1.1以上のことは何も言わない
 proxiesの役割について
 user agentの「確認」について
 opportunistic encryptionについて
 captive portalの振りをする悪人がいると検出できない
 HTTP/1.1ではプロキシのディスカバリについては何も定義しなかった
 ユースケースが大事
 cacheingは難しい
 クライアントからこれ持ってそうだからハッシュくれ、みたいに言えないとねー
 credentialとGPSなどのプライバシーは分けて考えないと

Proxyつづき
 5.8bil transactions (cisco)
 17% https
 1.8% of https connections → MITM
 serverから見るとリクエストがプロキシーされてようがMITM受けていようが
わからないのが問題
 会社やベンダーにroot CA certつっこまれる問題
 99%の人は証明書の問題を報告してほしくはない → 1%のリテラシーある人は
知りたい
 everything over httpsの世界をまず作って、それからだ
 CSSファイルは誰でも同じもの見るんだからキャッシュできるよね
 data integrityの話とserver authNの話は別? → いやどうだろう
 browser cacheだけ考えて、違うサイトのjquery.jsのハッシュがマッチしたら使
えるというのはscary
 script hash, script nonce: ハッシュとダイジェスト

今後の予定
 4月 WG Last Call
 6月上旬、米東海岸で第6回interim
 6/5-6 Bostonが有力

httpbis WG IETF89レポート

httpbis WG IETF89レポート

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(15)

Similar to httpbis WG IETF89レポート

Similar to httpbis WG IETF89レポート(20)

More from Kaoru Maeda

More from Kaoru Maeda(15)

Recently uploaded

Recently uploaded(11)

httpbis WG IETF89レポート