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レポート

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à httpbis WG IETF89レポート

Similaire à httpbis WG IETF89レポート (20)

Plus de Kaoru Maeda

Plus de Kaoru Maeda (15)

httpbis WG IETF89レポート