1.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS & LURK @ IETF 95
DeNA Co., Ltd.
Kazuho Oku
1

2.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
はじめに
 話者は暗号の専門家ではありません
 プロトコル実装はちょっとできる
⁃ H2O (HTTP/2)
 TLS「実装」のハックは多少したことがある
⁃ TLS 1.3は自分で実装するつもり
ツッコミお願いします m(__)m
2TLS & LURK @ IETF 95

3.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3
3TLS & LURK @ IETF 95

4.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3とは
 TLSの次期メジャーバージョン
⁃ 2016/5 WGLC (予定)
 主な変更:
⁃ Forward Secrecy (前方秘匿性)
⁃ より多くのデータを暗号化 (e.g. セッションID)
⁃ より高速なハンドシェイク (0-RTT / 1-RTT)
⁃ 脆弱性を産みにくい設計
• AEAD必須, 圧縮なし, リネゴシエーションなし, etc.
⁃ クライアント認証は、ハンドシェイク後に証明書の保
有証明として実現
4TLS & LURK @ IETF 95

5.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
Forward-secrecyとリザンプション
 TLS 1.2以前:
⁃ フルハンドシェイク (2-RTT)
⁃ リザンプション (1-RTT)
• 暗号鍵を使いまわし（正確にはTCP接続毎にFSでない）
 TLS 1.3:
⁃ フルハンドシェイク (1-RTT)
• 認証と暗号鍵の分離を強制 ((EC)DHE)
⁃ Pre-Shared Key (リザンプションに相当, 0-RTT)
• PSK+(EC)DHE: TCP接続毎の前方秘匿性(FS)を確保
• PSK-only: TLS 1.2以前と同様
5TLS & LURK @ IETF 95

6.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTT
 ハンドシェイク要求と同時にアプリデータ送信
 懸念点: アプリデータはリプレイ可能
⁃ 対策: アプリが気をつけて使う
6TLS & LURK @ IETF 95

7.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3 @ IETF 95
 WGLCにむけた作業
⁃ (未成熟な) 部分を削る
⁃ 細かな改善
 資料
⁃ https://www.ietf.org/proceedings/95/slides/slide
s-95-tls-2.pdf
⁃ https://www.ietf.org/proceedings/95/minutes/mi
nutes-95-tls
7TLS & LURK @ IETF 95

8.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
ダウングレード攻撃の検知
 要件
⁃ クライアントは、自分が送信したTLSバージョンがを
話すサーバに正しく伝わったか検証したい
⁃ TLS 1.2以前でのハンドシェイク完了時にも、検出で
きる必要がある
 手法
⁃ バージョンを、ServerRandomのprefixとして送信
• “DOWNGRD01”
⁃ TLS 1.3サーバがTLS 1.2以前のクライアントとハンド
シェイクする場合
8TLS & LURK @ IETF 95

9.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTTハンドシェイクの整理
 撤回されたもの
⁃ クライアント認証 (0-RTT)
⁃ (EC)DHE
 残るもの
⁃ PSK
⁃ PSK-(EC)DHE
 要は
⁃ 共通鍵を交換済の場合だけ0-RTT可能にする
9TLS & LURK @ IETF 95

10.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
(EC)DHE 0-RTT撤回の影響とは?
 PSKが使えないケースが影響をうける
⁃ 今後もPSKなら0-RTTできるわけで…
 例: out-of-bandでの(EC)DHE鍵の配布
⁃ サーバのDNSレコードに(EC)DHE鍵を入れておく
• 初回接続から0-RTT
 撤回理由（のひとつ）:
⁃ out-of-bandで鍵を配布&revokeする現実的な手法の
欠如
10TLS & LURK @ IETF 95

11.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTTハンドシェイクに失敗した場合の挙動整理
 決まった手順
1. サーバがHelloRetryRequest送信
2. クライアントはearly-dataの末尾をalertでマーク
3. early-dataは全てなかったことにしてフルハンドシェ
イクを続行
11TLS & LURK @ IETF 95

12.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0.5-RTT vs. リプレイ攻撃
 0.5-RTTとは
⁃ サーバがハンドシェイクとともに送るearly-data
 0.5 RTTを使いたいユースケース:
⁃ HTTP/2, SMTP, ...
 リプレイ攻撃が発生するケース:
⁃ PSK + client auth
 結論:
⁃ 0-RTT early-data同様、アプリが注意して使う
12TLS & LURK @ IETF 95

13.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
鍵の使い分け
 TLS 1.3ではハンドシェイクとアプリデータで異なる鍵を
使う
⁃ メリット: 権限分離可能
 問題: post-handshake messageをどう暗号化するか
⁃ post-handshake messageとは?
• NewSessionTicket, client-auth, KeyUpdate
⁃ 解決案:
• とりあえず復号して整合性確認
• ２重暗号化 ← 採用
• content-typeを書き戻す
⁃ 使う鍵は? → 専用の鍵を作ろう
13TLS & LURK @ IETF 95

14.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
鍵について整理しておくと…
 ２つのSecret
 SSとESから導出される鍵でメッセージを暗号化
⁃ handshake key, application key, post-handshake
key
⁃ Resumption Master Secretも同様に導出
 SSは0-RTTの暗号化に使用
14TLS & LURK @ IETF 95
Key Exchange Static Secret (SS) Ephemeral Secret (ES)
(EC)DHE (1-RTT) client & server ephemeral client & server ephemeral
PSK (0-RTT) pre-shared key pre-shared key
PSK+(EC)DHE (0-RTT) pre-shared key client & server ephemeral

15.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
他にあった議論
 対応する(EC)DHEのパラメータをサーバが告知したい
⁃ 「次からはこのパラメータを使ってほしいな」
⁃ supported_groups extensionを送ることが可能に
 TLS通信の改ざん不可能なモニタがほしい
⁃ KeyUpdateに受信通知をつければいい
⁃ 暗号鍵を更新後に古い鍵をモニタ装置に通知 → モニ
タは保存しておいた暗号文を解読
⁃ https://github.com/tlswg/tls13-spec/pull/426/
⁃ Status: parked
15TLS & LURK @ IETF 95

16.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
LURK
(Limited Use Remote Keys)
16TLS & LURK @ IETF 95

17.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
そもそものユースケース
 CDN (Content Delivery Network) の秘密鍵運用
 CDNは、世界各国に拠点を配置
⁃ そこから高速かつ安価にコンテンツの配信を代行
⁃ そのためにHTTPSを終端する
⁃ だが、秘密鍵の供託が必要な国もある
• 盗聴リスク????
 解決策:
⁃ 秘密鍵が必要な処理は、安全な拠点のサーバで行う
⁃ 安全じゃない拠点〜秘密鍵サーバは専用プロトコル
• これを標準化するのがLURK
17TLS & LURK @ IETF 95

18.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
他のユースケース
 コード署名の権利を委譲したい…
18TLS & LURK @ IETF 95

19.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
議論の焦点
 なんでも署名（暗号化）してしまう秘密鍵運用サーバの
存在意義って何？
⁃ 秘密鍵を供託してるのとリスクは大差ないのでは?
 そこを防ごうとすると、TLSプロトコル専用に、ハンドシ
ェイク部分を委譲する仕組みとならざるをえないのでは?
⁃ → WGのゴールって何なのさ？
19TLS & LURK @ IETF 95

20.
Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
おしまい
20TLS & LURK @ IETF 95