ietf91 honolulu httpbis wg report
DESCRIPTION
IETF91のhttpbis WGレポートですTRANSCRIPT
https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.
IETF91 Honoluluhttpbis WGレポート
株式会社レピダム
前田薫 (@mad_p)
http2 勉強会 #6 2014/11/25
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
目次
日本のコミュニティー活動報告(http2conf)
9.2.2問題
Client Authentication over New TLS Connection
Alt-Svc
proxy
その他
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF91概要
Honolulu
2014/11/09-14
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpbis WG
Tuesday HTTP/2: 9.2.2問題、クライアント認証、Alt-Svc他
Wednesday HTTP/2: 日本からの報告
proxy関連他
議事録
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf91/minutes.md
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HTTP/2 Local Activities in Japan
急遽5分もらって発表
http2 conferenceまとめ
最速実装ライブコーディング
実装増えたよ!
ほぼ毎月活動
「issuethon」がウケた
その結果…
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
http2studyの活動が認知されました!
httpbis WG議事録 Mark Nottingham (MN): nghttp2 is considered a
reference implementation. Language barriers make it hard to get the contributions
from Japan back into our work. Please keep up the excellent work, and tell us how we can help you.
仕様のAcknowledgements The Japanese HTTP/2 community provided an
invaluable contribution, including a number of implementations, plus numerous technical and editorial contributions.
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
9.2.2問題とは何か
http2study #6 2014/11/25
client
server
TLS層
HTTP層
TLS1.2でね、これこれの暗号方式でALPNで次はh1かh2ね
おっけー、じゃあ
TLS_RSA_WITH_AES_128_CBC_SHA
鍵とか交換鍵とか交換~
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
9.2.2問題とは何か
http2study #6 2014/11/25
client
server
TLS層
HTTP層
ちょっと待てー!そのcipher、
HTTP/2で禁止だから!
TLS1.2でね、これこれの暗号方式でALPNで次はh1かh2ね
おっけー、じゃあ
TLS_RSA_WITH_AES_128_CBC_SHA
鍵とか交換鍵とか交換~
安全な通信路できたよー次はh2でいい?
ALPNの情報見て先に聞いてくれよ
えー、おいらそんなAPIないもんー
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
9.2.2問題
HTTP/2仕様のセクション9.2.2 HTTP/2はcipher suiteに関する制限が強い
ephemeral key exchange (DHE, ECDHE), 圧縮なし, etc. INADEQUATE_SECURITYで接続を切る(MUST)
TLSネゴシエーションはプロトコルがHTTP/1.1なのかHTTP/2なのかわかる前に行われる HTTP/1.1をサポートするために古いcipherも必要 HTTP/2で禁止されているcipherで合意した後に、
ALPNでHTTP/2に決まったらどうする? 接続をいったん切って最初からより少ないsuiteでやり直せばいいが、それはやりたくない
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
white list案
9.2.2解決案(TLS1.3まにあわねーよ)
以下の6ステップで 1. Make cipher suite requirements specific to TLS 1.2
2. Nominate a fixed list of suites for use with H2+TLS12
3. Keep the required interop suite (mandatory to deploy)
4. Clarify that cipher suite requirements apply to deployments, not impl 5. Relax requirement to generate INADEQUATE_SECURITY
6. Require support for TLS_FALLBACK_SCSV w/ TLS1.3+ (?)
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
議論の結果
black list案: 既知のダメなスイートを静的に持つ
white list案では新規スイートが使われないため
if the ciphersuite selected for h2 is... BAD = peer MAY INADEQUATE_SECURITY
!BAD = peer MUST NOT INADEQUATE_SECURITY
Peers MUST NOT negotiate BAD
BAD: fixed in-spec black list
この案が有効と思うhumが多かった
http2study #6 2014/11/25
Client Authentication
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Client Authentication over New TLS Connection
draft-thomson-httpbis-cant
HTTP/2 over TLS1.2 や TLS1.3ではrenegotiationが禁止される/存在しない
spontaneous client authentication connectionを使い回している状態で後から認証が必要になった場合
これまではrenegotiationで対応していた
今後は401を返し、TLS接続からやり直す そのためのヘッダを提案
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
これまでの方法
http2study #6 2014/11/25
client server
GET /
200 OK
GET /intranet/calendar
TLS層
TLS層
HTTP層
そいつは認証必要
TLS renegotiation
クライアント証明書くれ
はーい
HTTP層
200 OK
TLS通信路
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
提案する方法(TLSをいったん切る)
http2study #6 2014/11/25
client serverGET /
200 OK
GET /intranet/calendar
TLS層
TLS層
HTTP層
そいつは認証必要
クライアント証明書あるよ
HTTP層
200 OK
TLS通信路
401 UnauthorizedWWW-Authenticate: ClientCertificate
realm="home", sha-256=NjUw...
GET /intranet/calendar
認証済
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
議論の結果
WGアイテムとして検討を続ける(hum)
意見など
WWW-Authenticateは対応するAuthorizationを使うのが前提では?
HTTP/1.1の他の認証方法との整合も必要
HTTP/1.1 over TLS1.3でもこの問題は発生
HTTP/2 over TLS1.2ではTLSネゴ直後にrenegotiation(HTTP/2のprefaceの前なら合法)
http2study #6 2014/11/25
Other Issues
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Alt-Svc関連 github issues
#36 Security Considerations: tracking using the alt-svc host name; #34 Alt-Svc-Used indicator granularity Alt-Svcでprotocol, hostが変わったかサーバーが知る術がない。とは言えあまり詳しくするとprivacy impactがある
#16 Alt-Svc alternative cache invalidation Alt-Svcでホストを受け取ったら古いの消すって本当? setで考えるといいのでは?
#12 Positive indicator of server understanding HTTP/1.1でだけ問題になる httpオリジンからhttpsへのAlt-Svcを送ると、http over TLSでアクセスしようとする。サーバーがそういうアクセス形態を予期していない場合、コンテンツを盗むアタックが可能
security considerationsに書く
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Proxies
Web Proxy Description draft-nottingham-web-proxy-desc WPD Proxiesというのを定義しよう
MUST support HTTP/2; Clients MUST use HTTP/2 over TLS SHOULD support CONNECT
Web Proxy Description (WPD) Format (JSON)も定義 PACでよくね? trusted middleboxはセキュリティー上はよくない。スノーデンのようなやつがシステム管理者をねらってエンドユーザーに知られずに盗聴しかけるのが心配
explicitly configured and working on behalf of user agentというのはいまのプロキシの実態に合っていない。いまのプロキシはon behalf of networkで動いている
middle-boxの扱いについてはi2rs BoFもある。AD預かり
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Proxies
WPD Proxy Discovery http://www.ietf.org/proceedings/91/slides/slides-91-
httpbis-0.pdf draft-chow-httpbis-proxy-discovery-00 https://??authority??/.well-known/web-desc-proxy 誰に聞くかという問題がある。ここでhttpsなのが重要
これだめだろ。オリジンauthority送るとMITM可能 最初に返事した者が正しいという保証はない。特にhotspotでは。最初のauthorityをどこに書くか
これってsecurityの話だよねー
http2study #6 2014/11/25
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
その他
HTTP/2関連
Opportunistic Security (github issues) 特に議論はなかった
#642: PRIORITYをidleにも送れるようにする件
interop issues, security issuesなどが指摘された
MLで検討
CONNECT methodにTunnel-Protocolヘッダをつける件
rtcwebが依存している
http2study #6 2014/11/25
Future
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
今後の予定
h2-16, HPACK-10 WGLCなし
次のDallasまでにはHTTP/2決着つけたい
mnot: Dallasではhttpbis WGないかもー
http2study #6 2014/11/25