ietf91 honolulu httpbis wg report

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


IETF91概要

Honolulu

2014/11/09-14

http2study #6 2014/11/25


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

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf91/minutes.md


HTTP/2 Local Activities in Japan

急遽5分もらって発表

http2 conferenceまとめ

最速実装ライブコーディング

実装増えたよ!

ほぼ毎月活動

「issuethon」がウケた

その結果…

http2study #6 2014/11/25


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


9.2.2問題とは何か

http2study #6 2014/11/25

client

server

TLS層

HTTP層

TLS1.2でね、これこれの暗号方式でALPNで次はh1かh2ね

おっけー、じゃあ

TLS_RSA_WITH_AES_128_CBC_SHA

鍵とか交換鍵とか交換～


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.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


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


議論の結果

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


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

http://tools.ietf.org/id/draft-thomson-httpbis-cant


これまでの方法

http2study #6 2014/11/25

client server

GET /

200 OK

GET /intranet/calendar

TLS層

TLS層

HTTP層

そいつは認証必要

TLS renegotiation

クライアント証明書くれ

はーい

HTTP層

200 OK

TLS通信路


提案する方法(TLSをいったん切る)

http2study #6 2014/11/25

client serverGET /

200 OK


TLS層

TLS層

HTTP層

そいつは認証必要

クライアント証明書あるよ

HTTP層

200 OK

TLS通信路

401 UnauthorizedWWW-Authenticate: ClientCertificate

realm="home", sha-256=NjUw...


認証済


議論の結果

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


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

https://github.com/httpwg/http-extensions/labels/alt-svc


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

http://tools.ietf.org/html/draft-nottingham-web-proxy-desc


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

http://www.ietf.org/proceedings/91/slides/slides-91-httpbis-0.pdf

http://tools.ietf.org/html/draft-chow-httpbis-proxy-discovery-00


その他

HTTP/2関連

Opportunistic Security (github issues) 特に議論はなかった

#642: PRIORITYをidleにも送れるようにする件

interop issues, security issuesなどが指摘された

MLで検討

CONNECT methodにTunnel-Protocolヘッダをつける件

rtcwebが依存している

http2study #6 2014/11/25

https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+is%3Aissue+label%3Aopp-sec

Future


今後の予定

h2-16, HPACK-10 WGLCなし

次のDallasまでにはHTTP/2決着つけたい

mnot: Dallasではhttpbis WGないかもー

http2study #6 2014/11/25

ietf91 honolulu httpbis wg report

Internet