http2study 20160423 IETF95 Report

https://lepidum.co.jp/

IETF 95 Report: httpbis, tls WG

株式会社レピダム

前田薫 (@mad_p)

http2study 2016/04/23



IETF95

Buenos Aires, Argentina, Apr 2-8

1002 participants

US, AR, CN, FR, DE, GB, CA, JP, BR, others



httpbis WG (Monday and Thursday)

Working group to maintain and develop the "core" specifications for HTTP.

Chair: Mark Nottingham (Akamai)

agenda: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/agenda.md

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


https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/agenda.md

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


Topics from httpbis

Finished Documents RFC7694: Client Initiated Content Encoding RFC7725: An HTTP Status Code to Report Legal Obstacles RFC7838: Alternative Services

Opportunistic security Character Encoding and Language for Parameters Client hints HTTP Encryption Content Encoding JSON Header Field Values ORIGIN frame and connection coalescing Client authentication with certificates Cache Digest Decomposing the Hypertext Transfer Protocol Merkle Integrity Content Encoding Secure Content Delegation using HTTP and Caching Secure HTTP Content using Blind

Caches



Opportunistic security

draft-ietf-httpbis-http2-encryption-04

だいたい議論は終わり?

.well-known/http-opportunistic の問題を検討 {

"origins": ["http://example.com", "http://www.example.com:81"],

"commit": 86400

}

commit: この期間、セキュアコンテンツを提供する commitの時間とwell-knownリソースの寿命を分離


https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04


Character Encoding and Language for Parameters

draft-ietf-httpbis-rfc5987bis-01

HTTPヘッダの国際化方法 foo: bar; title*=utf-8'en'%C2%A3%20rates

foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates

「=」を「*=」に

「エンコーディング'言語'%エンコした文字列」

くぎりがアポストロフィーなのアレだけど


https://tools.ietf.org/html/draft-ietf-httpbis-rfc5987bis-01


Client Hints

draft-ietf-httpbis-client-hints-00 リソースのレイアウトなど、デバイスに合わせて最適化したい。DPR

(Device Pixel Ratio), Width of the screen, or Viewportなどを使う。いままではUAを見て判定していた

RFC7234 では"Vary"ヘッダを使って、UAやクッキーに依存したコンテンツであることを示せると定義

Client Hintsはクライアントがその情報をサーバーに伝えるヘッダ群のこと DPR: 2.0 Width: 320 Viewport-Width: 320

これらの値に依存してコンテンツを作った場合、サーバーはVaryヘッダに加えてKeyヘッダも出す

サーバーはAccept-CHヘッダを送って、クライアントがClient Hintsを送ってくれれば考慮するよーと知らせることも可能


https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-00


HTTP Encryption Content Encoding

draft-ietf-httpbis-encryption-encoding-01

HTTPペイロードを暗号化する HTTP/1.1 200 OK

Content-Type: application/octet-stream

Content-Encoding: aesgcm

Connection: close

Encryption: keyid="http://example.org/bob/keys/123";

salt="XZwpw6o37R-6qoZjw6KwAw"

AES-GCM固定→ CFRGから助言もらわないとね

EKR: 暗号化を考えるなら署名もいっしょでないと


https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-01


JSON Header Field Values

draft-reschke-http-jfv-03

HTTP ヘッダはparseしにくい。特に同一のフィールド名が複数あって連結するときや、エスケープがある場合→ JSONにしようぜ

JSON ただし全体を [] で囲っているとして扱う WWW-Authenticate: { "Newauth" : { "realm": "apps", "type" : 1,

"title": "Login to ¥"apps¥"" }},

{ "Basic" : { "realm": "simple"}}

JSONがchattyなら CBOR使えばいいよねー

Date型とか導入したくなるのをどうするか


https://tools.ietf.org/html/draft-reschke-http-jfv-03


ORIGIN Frame

draft-nottingham-httpbis-origin-frame-01 同一のHTTP/2 connection上で、他のオリジンも提供できることを示すORIGIN frame

connection coalescingできることを明示


https://docs.google.com/presentation/d/1r7QXGYOLCh

4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/Ilya

https://tools.ietf.org/html/draft-nottingham-httpbis-origin-frame-01

https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/


Client authentication with certificates

draft-thomson-http2-client-certs-02 リアクティブなクライアント証明書認証には問題があった TLS の client cert authはセッション単位

TLS を開始した後でクライアント証明書認証の必要なリソースにアクセスしたらどうする?

TLS 1.2では renegotiation; TLS 1.3では spontaneous authを使う不統一。めんどう h2ではどのアクセスが認証を必要としたのかわからない

解決方法: 証明書検証に必要な道具をHTTP/2 Frameとして実装 request-idを導入し、対応が取れるように connection単位で証明書一覧を管理、streamごとに使う


https://tools.ietf.org/html/draft-thomson-http2-client-certs-02


Client Cert Example


https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf


Cache Digest

draft-kazuho-h2-cache-digest

CACHE_DIGESTフレームを定義


以前の提案ではヘッダだったが、本提案ではフレームconnectionにつき1回送ればよい

http://www.slideshare.net/kazuho/http-58452175

https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-00

http://www.slideshare.net/kazuho/http-58452175


Merkle Integrity Content Encoding

draft-thomson-http-mice-00 SRI (Subresource Integrity)は遅い

<script src="https://example.com/main.js"integrity="sha384-TNShKsRojXl/CWi2MfheXDy9KEk..." />

全部読み終わってからでないと検証できないプログレッシブロードできない

エラーハンドリングが難しい

解決策: ハッシュチェインハッシュの生成: コンテンツの後ろから、ブロックごとにハッシュを計算し、各ブロックの前に置く

最初のブロックのハッシュに署名してヘッダに置く


https://tools.ietf.org/html/draft-thomson-http-mice-00


MICE: Generation


https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/MICE.pdf

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/MICE.pdf


MICE: Validation



Secure Content Delegation using HTTP and Caching Secure HTTP Content using Blind Caches

draft-thomson-http-scd-00

draft-thomson-http-bc-00

ベースになっているのはContent-Encoding:

out-of-band

CE: OOB、みんな知ってる?


https://tools.ietf.org/html/draft-thomson-http-scd-00

https://tools.ietf.org/html/draft-thomson-http-bc-00


'Out-Of-Band' Content Coding for HTTP

draft-reschke-http-oob-encoding-04


Request:

GET /test HTTP/1.1

Host: www.example.com

Accept-Encoding: gzip, out-of-band

Response:

HTTP/1.1 200 OK

Date: Thu, 14 May 2015 18:52:00 GMT

Content-Type: text/plain

Cache-Control: max-age=10, public

Content-Encoding: out-of-band

Content-Length: 145

Vary: Accept-Encoding

{

"URIs": [

"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"

],

"fallback": "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"

}

クライアントは、ここを取りに行って、このへんのヘッダと合体させてHTTPレスポンスを作る

暗号化も可能。キーをCrypto-Keyで渡す

https://tools.ietf.org/html/draft-reschke-http-oob-encoding-04


Caching Secure HTTP Content using Blind Caches


https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf

シェアドキャッシュができますね!

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf


Secure Content Delegation using HTTP

Proxyが中身を見れない状態でシェアドキャッシュできた!

同じキャッシュを使ってる人は、オリジンから同じリソースのURIもらえば、Proxyが持ってるキャッシュもらえますね!

オリジンにURI教えてもらうために1RTTもったいないよね

Server Pushで送っちゃおう! コンテンツ関連のヘッダなしだと、HPACKでよく縮むしね!



Server Push活用


この1RTT

遅いなあ

×

Server Pushで0RTT

いきなり近くに取りに行ける


Future of HTTP

HTTP Workshop 2015, 2016 Jul 2016 in Stockholm

https://httpworkshop.github.io/

Jul 2015 in Münster https://github.com/HTTPWorkshop/workshop2015/wiki/2015-Report

List of ideas for HTTP https://github.com/HTTPWorkshop/workshop2015/wiki/HTTP-Ideas

Some of them have been proposed in IETF http-wg

HTTP/2 Extensions enable experiments in the field(e.g. Cache digest)


https://httpworkshop.github.io/

https://github.com/HTTPWorkshop/workshop2015/wiki/2015-Report

https://github.com/HTTPWorkshop/workshop2015/wiki/HTTP-Ideas


tls WG

The primary purpose of the working group is to develop (D)TLS v1.3.

Chair

Joe Salowey, Sean Turner

agenda: https://tools.ietf.org/wg/tls/agenda?item=agenda-95-tls.html

minutes http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-

tls?showControls=true&showChat=true&showLineNumbers=true&useMonospaceFont=true


https://tools.ietf.org/wg/tls/agenda?item=agenda-95-tls.html

http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-tls?showControls=true&showChat=true&showLineNumbers=true&useMonospaceFont=true


TLS 1.3 topics

https://www.ietf.org/proceedings/95/slides/slides-95-tls-2.pdf

Changes since draft-10

Outstanding consensus calls

1-RTT PSK and session tickets

Context values

Key schedule and key separation

0-RTT details


https://www.ietf.org/proceedings/95/slides/slides-95-tls-2.pdf


Changes since draft-10

Restructure authentication along uniform lines * Restructure 0-RTT record layer * Reset sequence numbers on key changes Import CFRG Curves Zero-length additional data for AEAD Revised signature algorithm negotiation * Define exporters * Add anti-downgrade mechanism * Add PSK cipher suites



Any Questions? Please Give Feedbacks!


mailto:[email protected] / twitter: @mad_p



Internet

http2study 20160423 IETF95 Report