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

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リソースの寿命を分
離

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
 「=」を「*=」に
 「エンコーディング'言語'%エンコした文
字列」
 くぎりがアポストロフィーなのアレだけど

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を
送ってくれれば考慮するよーと知らせることも可能

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: 暗号化を考えるなら署名もいっしょでな
いと

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型とか導入したくなるのをどうするか

ORIGIN Frame
 draft-nottingham-httpbis-origin-frame-01
 同一のHTTP/2 connection上で、他のオリジンも
提供できることを示すORIGIN frame
 connection coalescingできることを明示
https://docs.google.com/presentation/d/1r7QXGYOLCh
4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/
Ilya

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ごとに使う

Client Cert Example
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

Merkle Integrity Content Encoding
 draft-thomson-http-mice-00
 SRI (Subresource Integrity)は遅い
 <script src="https://example.com/main.js"
integrity="sha384-TNShKsRojXl/CWi2MfheXDy9KEk..." />
 全部読み終わってからでないと検証できない
 プログレッシブロードできない
 エラーハンドリングが難しい
 解決策: ハッシュチェイン
 ハッシュの生成: コンテンツの後ろから、ブロック
ごとにハッシュを計算し、各ブロックの前に置く
 最初のブロックのハッシュに署名してヘッダに置
く

MICE: Generation
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、みんな知ってる?

'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で渡す

Caching Secure HTTP Content using
Blind Caches
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)

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=tru
e

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

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:maeda@lepidum.co.jp / twitter: @mad_p

http2study 20160423 IETF95 Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to http2study 20160423 IETF95 Report

Similar to http2study 20160423 IETF95 Report (20)

More from Kaoru Maeda

More from Kaoru Maeda (17)

http2study 20160423 IETF95 Report