Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IETF91 Honolulu httpbis WG Report

1,211 views

Published on

IETF91のhttpbis WGレポートです

Published in: Internet
  • Be the first to comment

IETF91 Honolulu httpbis WG Report

  1. 1. https://lepidum.co.jp/ Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. IETF91 HonoluluhttpbisWGレポート 株式会社レピダム 前田薫(@mad_p) http2 勉強会#6 2014/11/25 http2study #6 2014/11/25
  2. 2. 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
  3. 3. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ IETF91概要 Honolulu 2014/11/09-14 http2study #6 2014/11/25
  4. 4. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ httpbisWG 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
  5. 5. 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
  6. 6. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ http2studyの活動が認知されました! httpbisWG議事録 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
  7. 7. 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 鍵とか交換 鍵とか交換~
  8. 8. 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ないもんー
  9. 9. 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
  10. 10. 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 interopsuite (mandatory to deploy) 4. Clarify that cipher suite requirements apply to deployments, not impl5. Relax requirement to generate INADEQUATE_SECURITY 6. Require support for TLS_FALLBACK_SCSV w/ TLS1.3+ (?) http2study #6 2014/11/25
  11. 11. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ 議論の結果 black list案: 既知のダメなスイートを静的に持つ white list案では新規スイートが使われないため if the ciphersuiteselected 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
  12. 12. Client Authentication
  13. 13. 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
  14. 14. 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 層 そいつは 認証必要 TLSrenegotiation クライアント証明書くれ はーい HTTP 層 200 OK TLS通信路
  15. 15. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ 提案する方法(TLSをいったん切る) http2study #6 2014/11/25 client server GET / 200 OK GET /intranet/calendar TLS 層 TLS 層 HTTP 層 そいつは 認証必要 クライアント証明書あるよ HTTP 層 200 OK TLS通信路 401 Unauthorized WWW-Authenticate: ClientCertificate realm="home", sha-256=NjUw... GET /intranet/calendar 認証済
  16. 16. 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
  17. 17. Other Issues
  18. 18. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ Alt-Svc関連githubissues #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を送ると、httpover TLSでア クセスしようとする。サーバーがそういうアクセス形態を予 期していない場合、コンテンツを盗むアタックが可能 security considerationsに書く http2study #6 2014/11/25
  19. 19. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ Proxies Web Proxy Descriptiondraft-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
  20. 20. 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
  21. 21. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ その他 HTTP/2関連 Opportunistic Security (githubissues) 特に議論はなかった #642: PRIORITYをidleにも送れるようにする件 interopissues, security issuesなどが指摘された MLで検討 CONNECT methodにTunnel-Protocolヘッダを つける件 rtcwebが依存している http2study #6 2014/11/25
  22. 22. Future
  23. 23. Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. https://lepidum.co.jp/ 今後の予定 h2-16, HPACK-10 WGLCなし 次のDallasまでにはHTTP/2決着つけたい mnot: DallasではhttpbisWGないかもー http2study #6 2014/11/25

×