JPNIC News & Views vol.1460【臨時号】第97回IETF報告 [第4弾] セキュリティエリア関連報告～新しいTLSのバージョンはどうなる？～

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1460【臨時号】2016.12.19 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1460 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年11月13日(日)～18日(金)にかけて、韓国のソウルにて開催された第97
回IETFミーティングの報告を、vol.1455より連載にてお届けしています。本
号では第4弾として、セキュリティエリアの動向を取り上げます。

今回の会議ではTLS1.3の検討がいよいよ大詰めを迎え、これまで暫定的な名
称として使われていたTLS1.3が、会期終了直後に正式なバージョン名として
決定しました。

なお、連載の最終回ではDNS分野の動向をお届けする予定です。これまでに発
行したバックナンバーについては、下記のURLをご覧ください。

  □第97回IETF報告

    ○[第1弾] 全体会議報告 (vol.1455)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1455.html

    ○[第2弾] IPv6関連WG報告 ～v6ops、sunset4 WGに関して～ (vol.1456)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1456.html

    ○[第3弾] トランスポートエリア関連報告 (vol.1457)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1457.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第97回IETF報告 [第4弾]  セキュリティエリア関連報告
                           ～新しいTLSのバージョンはどうなる？～
                                               ヤフー株式会社 大津繁樹
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IETF 97は、2016年11月13日(日)から18日(金)にかけて、韓国・ソウルで開催
されました。この会議では、TLS1.3のワーキンググループラストコール(WGLC)
が終了し、時を同じくして第1回のQUIC WGを開始するといったこともあり、
個人的に何か節目を感じるような会議でした。

QUICは、Google社が提唱するUDPをベースに開発されたWeb向けの新プロトコ
ルですが、既存のIETFエリア・ワーキンググループ(WG)の境界を塗り替える
QUIC WGの第1回セッションは、300名の部屋が満席になり、立ち見を含めて400
名近くが会場に集まりました。最終的なIETF 97のオンサイト登録者が982名
でしたので、およそ半数近くの参加者がQUICのセッションに参加していたこ
とになります。

QUICの標準化はまだ始まったばかりですが、そのセキュリティ機能の根幹と
なるTLS1.3の標準化は最終段階です。これまで先送りしてきたTLS1.3のブラ
ンド名変更、すなわち新しいTLSに関してバージョンの呼び方を変えるかどう
かを決定する時が訪れました。一旦IETF会場でハミング採決をしましたが、
その後のメーリングリスト(ML)での意見招集で、新しいTLSのバージョンをめ
ぐる大議論が起きています。

このような動向を踏まえ、今回のIETF 97での、TLS WGの動向について報告し
ます。

IETF 97では、これまで通りTLS WGは2セッションが開催されました。これま
で時間の大半を費やしてきたTLS1.3の議論は1時間弱で終わり、TLS1.3の仕様
化後を前提としたさまざまな機能の検討が始まりました。アジェンダ順に簡
単に内容をまとめます。


■  OpenSSL Status

OpenSSLチームのメンバーから、OpenSSLの開発状況について説明がありまし
た。現在、OpenSSLは開発環境をGitHubに移行し、外部からのフィードバック
を積極的に受けるよう開発状況の透明性を高めています。TLS1.3対応は、現
在鋭意開発中で、最新のOpenSSL-1.1.0とAPI/ABI互換のまま、次の
OpenSSL-1.1.1のリリースに含まれる予定です。安定性を向上させるため、
BoringSSLとのテストを共通化して、Google社との相互接続試験も進めている
との報告がありました。


■ TLS1.3

2013年から検討が開始されたTLS1.3は、その仕様がほぼ固まってきました。
Google ChromeやMozilla FirefoxなどWebブラウザでの試験実装も進み、各種
サーバとの相互接続試験も行われています。2016年10月27日(木)にdraft-18
のWGLCが始まり、IETF 97閉会直後の11月20日(日)に終了しました。主に今回
のセッションでは、WGLC中に受けたフィードバック修正検討に対する議論が
行われました。

・バージョンネゴシエーションの明確化

TLS1.2までのバージョンネゴシエーションは、仕様に不適合な実装が数多く
存在し、ブラウザベンダーなどはその対応に頭を悩ませてきました。そこで
TLS1.3は、これまでの仕組みを捨て去り、新しくsupported_versionという拡
張領域でバージョンネゴシエーションをするように変更しました。しかし、
TLS1.2や1.3の利用しか想定していなかったため、TLS1.1とか1.0で合意して
しまうエッジケースに関して明確に規定されていませんでした。今回明確に、
TLS1.2より前のバージョンは、supported_versionのリストに入れないことを
推奨する記述を追記しました。

・exporter鍵の導出方法変更

アプリケーションなどTLS通信以外の目的で利用するexporter鍵を導出する際
に、HKDF (HMAC-based Extract-and-Expand Key Derivation Function)にハッ
シュ値を使うことが明確に規定されていなかったので、ハッシュ計算したコ
ンテキスト値を入れるよう記述を明確化しました。

・ハンドシェイクにおける拡張機能に関するやり取りの統一化

TLS1.3ではClientHello/ServerHello以外に、Certificateにも拡張フィール
ドを付与できるようになりましたが、クライアント認証に使われる
CertificateRequestだけ、まだ固有の拡張フィールドを使っていました。そ
こでCertificateRequest書式を見直し、他のハンドシェイクと同一の拡張
フィールドを利用するように変更しました。これによって、ハンドシェイク
中の拡張フィールドの扱いを統一化しました。

・暗号化されたデータのRecordLayerサイズの切り詰め

TLSは従来、レコードヘッダを5バイト付けていました。タイプ・バージョン
番号を示す頭の3バイトは固定されているため無駄な領域でしたが、ハンド
シェイクが完了した後ならその無駄な部分を切り詰めることができるのでは
という提案です。書式が変わることで、暗号化・非暗号化のデータで混乱し
ないよう、先頭の1ビットを立てて区別する対応も加えました。しかし、ミド
ルボックスが書式が異なることをチェックしてブロックする可能性もあるた
め、年末にかけてMozillaでフィールドテストを行って、透過性の判断を行う
ことになりました。

・鍵の有効性

draft-18までは、暗号学的評価を元に1/2^57の衝突可能性を考慮して、単一
の鍵で暗号化できるレコード数の上限を、AES-GCMで最大2,400万に決定して
いました。アメリカ国立標準技術研究所(NIST)の暗号学者から、厳しすぎる
のでもう少し緩和したらどうかという提案が行われ、まだ議論が続いていま
す。

・ECDH楕円点のバリデーション

ECDH (Elliptic Curve Diffie-Hellman key exchange)で交換する、楕円点の
チェックを追記する提案が議論されました。同様の内容が外部仕様に規定さ
れており、記述が重なることが懸念されましたが、実装者が膨大な仕様書を
読み解く労力を軽減させるメリットの方が大きいので、TLS1.3の仕様に記述
を加えることになりました。

・TLS1.3の状態遷移

次のdraft-19で、TLS1.3のstate machineの記述を追加することになりまし
た。

・今後のスケジュール

IETF 97の終了直後にWGLCが終了するため、2016年12月頭に今回の検討部分を
取り込んだdraft-19をリリースする予定です。その後、12月下旬までMozilla
によってレコードヘッダ変更に伴う透過性テストを行います。暗号学者によ
るレビューを2017年1月までに完了し、順調にいけば翌2月にIETFラストコー
ル/IESG (Internet Engineering Steering Group)レビュー提出を予定してい
ます。既に12月6日の時点でまだdraft-19は完成していませんので、予定が遅
れるかもしれません。


■ TLS1.3のリブランド

TLS1.3は、従来のTLS1.2を通すミドルボックスの影響を受けないよう、初期
ハンドシェイクのデータ書式のみTLS1.2を踏襲するようにしました。しかし、
やり取りするデータやハンドシェイクの仕組みは、TLS1.2からかなり大きく
変更されています。一方、TLS1.3のハンドシェイクでやり取りするバージョ
ン番号は、SSL時代のものを引き継いた0304 (SSL3.4)の値になっています。
もはやTLS1.3の1.3というバージョン番号は、TLS1.2の次であること以外に意
味がありません。

このようなことから、仕様検討の初期に1.3というバージョンを変更すべきだ
という意見が出されていましたが、仕様化を進めることを優先するため、バー
ジョンに関する議論は議長の判断で一旦先送りとされました。今回晴れてWGLC
終了を迎え、バージョン変更について決着する時が来ました。現在の技術的
仕様にまったく変更を加えないことを前提として、バージョンを変更するか
どうかの提案を採決します。マーケティング効果を狙って、新しいTLS仕様の
ブランド名を変更するかどうかということを決めるのです。

IETF 97の会場で候補に挙がったのは、TLS1.3、TLS2.0、TLS2、TLS4の四つで
した。TLS2.0とTLS2は、TLS1.2から大幅に仕組みを変更したという意図を外
部に示すことになりますが、名称的にSSL2.0との違いがわからず、混同され
る恐れがあります。TLS4は、SSL2.0やSSL3.0との混同の恐れもなく、新しい
プロトコルであることを示すことができます。しかし、TLS2.0や3.0が欠番に
なっているため、突然4にバージョンが上がったことに対して驚きや疑問を受
けるかもしれません。

会場では、この4択でハミングによる採決が行われました。私はTLS2.0に賛同
しましたが、結果TLS1.3のまま変更しないことが大差で決まりました。議長
は、最終的にはMLに諮り決定をすることを申し送って終了しましたが、その
MLで、TLS1.3の現状維持とTLS4への変更を支持するメンバーとの間で、大議
論が発生しました。

TLS4への変更を希望する理由は、やはりSSLの名称がまだ世の中に定着してお
り、SSL3.0よりも新しいものであることを印象づける狙いを重要視したいか
らです。IETF 97後ML上で130通以上やり取りがあり、12月3日に議長によって
意見招集は締め切られましたが、本稿の執筆時点(12月6日)には結論は出てい
ません。本稿が発行される頃には決定しているでしょう。新しいTLS仕様は、
順調にいけば来年にはRFCが発行されます。どんなブランド名になるのか楽し
みです。

  ※ その後、12月14日にtls wgの議長から「TLS1.3の方が支持が多いと判断
     して、TLS1.3のままにすると決定した」との報告がありました


■ データセンター内のTLSの透明性

普段IETFに参加していない、エンタープライズ系の発表者によるプレゼンテー
ションが行われました。US Bank社など大規模な金融システムでは、データセ
ンター内部でインターネットから数千のアプリケーションに向けて、多段の
TLS接続が行われています。そこではログインエラーなどの原因を調査する
際、別途保存されたTLSの通信データを復号して、問題特定を行う運用を行っ
ています。

TLS1.2まではRSA鍵交換方式が使えていたので、このような運用は可能でし
た。しかしTLS1.3になると、Perfect Forward Secrecy (PFS)の鍵交換に限定
されます。これでは、後から暗号化データを復号することは困難です。そこ
で、PFSではない固定化したDiffie-Hellman (DH)の鍵交換を、TLS1.3に利用
可能にする仕様の提案が行われました。

質疑においてPFSの無効化に賛同する意見は少なく、代わりにTLS1.2を継続し
て利用する方法、一時鍵を保存する方法などが提案されました。また、一時
的なDH鍵か固定化したDH鍵なのか、実質的にプロトコルではチェックするこ
とができないため、わざわざ仕様を提案せず勝手に固定DH鍵交換利用する運
用を行えば良いという意見も出されました。結局結論は出ませんでしたが、
引き続き金融セクターとの意見交換を続けていくことが確認されました。


■ TLS1.3のテストベクター

TLS1.3を実装する際に、テストベクターがあれば役に立つとの要望を受け、
Mozillaがテストデータをドラフトとして用意しました。WGドラフトとして採
択されました。

■ Exported Authenticators

httpbis WGでは、多重化接続のHTTP/2上でクライアント認証を実現する、
Secondary Certificateが検討されています。この仕様をヒントに、TLSレイ
ヤで同様の機能を実現できるようにした仕様です。この機能によって、クラ
イアント認証だけでなくサーバ・クライアント間で、一度TLS接続した後に追
加で別の証明書でサーバ認証が行えるようになります。この仕組みは、TLSの
ハンドシェイクとは独立して認証のやり取りを行うため、サーバ・クライア
ントのTLS状態を変えることもありません。セキュリティ評価などがこれから
で、まだWGドラフトへの採用は早急であるとの判断が示されましたが、引き
続き検討事項として議論していくことになりました。

■ DTLS1.3

TLS1.3仕様化が見えてきたことから、DTLS1.3の仕様化開始が宣言されまし
た。DTLS1.3では、DTLS1.2と機能がかぶるハンドシェイクタイプの廃止や、
QUICのような明示的なAckの導入、epochの扱いの修正などの検討が必要です。
さらに、NAT対応するよう新しくConnection IDの機能を導入するかどうかの
検討も行います。現状のドラフトがTLS1.3の古い仕様をベースとしているの
で、draft-18ベースにドラフトをアップデートして、次回シカゴでWGドラフ
トへの採用を問う方向が示されました。


■ IoT利用に向けて最適化されたDTLS

IoT利用のために、DTLSにConnection IDを付与する拡張を付ける提案が説明
されました。IoT環境では、NATタイムアウトを避けるためのkeep-aliveの維
持は難しく、QUICで採用されているようなConnection IDによるresume機能が
有効に働く可能性が高いです。QUICの利用検討はどうするのか、Connection
IDのサイズはどうするのか、negotiationが必要なのか、といった質疑が行わ
れました。


■ TLS拡張によるDNSSECバリデーションチェーン

DNSSECのchain情報をTLS拡張に埋め込んで、TLSサーバからクライアントへ送
信する仕様の検討が進められています。これによって、DANE (DNS-based
Authentication of Named Entities)とDNSSECの認証がDNSの問い合わせをせ
ず、TLS経由で認証情報を入手できるようになります。質疑では、TLS1.3で大
きく変更が入っているので、Client認証のサポートはTLS1.3の仕様化後に延
期した方がいいと意見が出されました。TLS1.3のCertificate拡張利用して、
さまざまなタイプも送れるように利用を広げられないか、最終的にはTLSを
使ったDNS情報のプッシュにつながるのではないか、といった意見も出されま
した。


■ 代理認証(Delegated Credentials)

秘密鍵をサーバ側に保持せず集中管理できるようにするのは、特にマルチテ
ナントのCDNプロバイダーなどが望んでいるアーキテクチャです。そのままで
は秘密鍵サーバへのRTT (Round Trip Time)の影響が大きいことから、サーバ
認証を別の方法で短期的に委任できる、有効な方法を検討する仕様が説明さ
れました。三つの方式が提案されましたが、End Entity証明書が署名した
Proxy証明書のようなX.509証明書を利用する方式と、公開鍵を含む独自フォー
マットを利用する方式の二つに対して議論が集中しました。前者は既存のPKI
ライブラリが利用できるが、後者は独自書式であるため処理が簡略化できる
といったメリットがあります。本ドラフト採用はまだ見送りにして、引き続
き検討を続ける方向が決まりました。


■ Trust on First Use - Ticket pinning

TLS ticketの仕組みを流用してサーバ認証を補完し、証明書の不正発行を検
知する仕組みの提案です。有効期限付きのpinning ticketを使って、クライ
アント・サーバ間でサーバ認証の強化を図ります。同様の対策にHPKP (HTTP
Public Key Pinning)がありますが、HTTPSでしか利用できず、証明書入れ替
え時にミスると大きな障害につながるといった運用課題がありました。Ticket
pinningは、ハンドシェイクに伴いticketが自動更新され、証明書入れ替え時
の運用に関する問題などの改善も狙っています。ただし、ticketを暗号化す
る鍵の管理やローテーションにおいては同様の運用課題が存在し、チケット
を渡す際のプライバシー問題が発生するのではないかといった指摘もされま
した。


■ 来年の注目はQUICに

TLS1.3のRFC化が見えてきたことから、今後新しいインターネットプロトコル
の開発はQUICに移るでしょう。UDP上でTCPとTLS同等の仕組みを実現し、より
モバイルネットワークに最適化される機能が付与されるQUICは、これまでの
TCP/IPの世界を再構築するものです。2017年に集中的に仕様検討が進められ、
2018年中の仕様化完了をめざしています。QUICを中心とした来年のIETF標準
化活動は、非常に注目されることになるでしょう。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1460/f256a0c41f6d878e9f3f4341ba68e2a2 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1460/606001dfaaf0adbd7bd0f51fcd9d9283 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.1460 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2016 Japan Network Information Center
このページを評価してください
