Network Working Group S. Hollenbeck Internet-Draft VeriSign, Inc. Updates: 2246 (if approved) November 20, 2003 Expires: May 20, 2004 Transport Layer Securityプロトコルにおけるデータ圧縮方法 draft-ietf-tls-compression-06.txt このメモの位置付け このドキュメントはインターネットドラフトであり、RFC2026の第10章に記載 されているすべての条項に従う。 インターネットドラフトは、Internet Engineering Task Force(IETF)とその エリア、そしてそのワーキンググループにおいて作成中のドキュメントのこと である。その他のグループが、作成中のドキュメントをインターネットドラフト として配布することも認められている。 インターネットドラフトは最大6ヶ月間有効で、その後アップデートや置き換え をすることができる。もしくは、他のドキュメントによりいつでも無効にする ことができる。インターネットドラフトを参考文献として引用すること、もし くは "work in progress" 以上の扱いで引用するのは適切ではない。 現在のインターネットドラフトは、次のところからアクセスすることができる。 http://www.ietf.org/ietf/1id-abstracts.txt インターネットドラフトのミラーサイトのリストは、次のところからアクセス することができる。 http://www.ietf.org/shadow.html 本ドキュメントは2004年5月20日まで有効である。 著作権 Copyright (C) The Internet Society (2003). All Rights Reserved. 要旨 Transport Layer Security (TLS) プロトコル (RFC 2246) には、TLSハンド シェイクプロトコルにおいてデータロスのない圧縮方法を選択するネゴシ エーションを行い、TLSレコードプロトコルにおいてこの選択された方法を 適用する機能がある。TLSでは現在1つの標準圧縮方法を規定している。 それは、レコードプロトコルを通じて交換されるデータは圧縮されない、 という方法である。本ドキュメントでは、TLSにおいて使用されるデータ ロスのない圧縮アルゴリズムとしてさらに1つの圧縮方法を示す。そして、 さらなる圧縮方法を規定するための方法を示す。 本ドキュメントで使用する慣用表現 本ドキュメントに現れるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"は、 RFC2119 [1] で示されるように解釈されなければならない。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. データ圧縮方法 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 圧縮処理のヒストリとパケット処理 . . . . . . . . . . . . . . . 5 2.2 ZLIB 圧縮方法 . . . . . . . . . . . . . . . . . . . . . . . . 5 3. 知的所有権に関する考察 . . . . . . . . . . . . . . . . . . . . 6 4. 国際化に関する考察 . . . . . . . . . . . . . . . . . . . . . . 7 5. IANAに関する考慮事項 . . . . . . . . . . . . . . . . . . . . . 8 6. セキュリティに関する考察 . . . . . . . . . . . . . . . . . . 9 7. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 参考情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . . 12 知的所有権と著作権表示 . . . . . . . . . . . . . . . . . . . . 13 1. はじめに Transport Layer Security (TLS) プロトコル (RFC 2246, [2]) には、TLSハンド シェイクプロトコルにおいてデータロスのない圧縮方法を選択するネゴシエー ションを行い、TLSレコードプロトコルにおいてこの選択された方法を適用する 機能がある。TLSでは現在1つの標準圧縮方法、CompressionMethod.nullを規定 している。これは、レコードプロトコルを通じて交換されるデータは圧縮されない、 という方法である。この1つの圧縮方法があることで、TLS実装間の相互運用が 可能となることが確実となる。しかし、他に標準化された圧縮方法がないため、 データ圧縮処理を含む、相互運用可能な実装の開発が制限されている。 TLSは、World Wide Webにおけるクライアント-サーバコネクションをセキュアに するために、幅広く使用されている。これらのコネクションは通常、持続時間が 短く、比較的少量のデータを交換するのに使用されているが、TLSではまた、 コネクションの持続時間が長く、数千もしくは数百万オクテットのデータ量の 交換が可能な環境でも使用することができる。例えばXML [4] はインターネット におけるデータ表記法としてその使用が拡大しているが、XMLで記述されたデータ は冗長性が高くなる傾向がある。TLSにおいて圧縮処理を行うことは、大量の データを交換する際の、帯域幅とレイテンシを低減するための1つの方法となる。 本ドキュメントでは、TLSにおいて使用されるデータロスのない圧縮アルゴリズム 方法として1つの圧縮方法を示す。この圧縮方法に関する圧縮データフォーマット や圧縮アルゴリズムの標準化については、本ドキュメントの範囲外である。 2. データ圧縮方法 TLS [2] では、第6.1節と第7.4.1.2節、付録A.4.1とA.6において、以下の構造体 を定義している。 enum { null(0), (255) } CompressionMethod; これにより、以後の仕様書においては、最大で256種類の圧縮方法を規定する ことができるとされている。本ドキュメントではこの定義をアップデートし、 指定可能な値の範囲を3つに分割する。 1. 0 (ゼロ) から 63 (0x3F) までの領域は、IETFのTLSワーキンググループに よる標準化活動で割り当てられる値として予約される。 2. 64 (0x40)から 192 (0xC0) までの領域は、TLSワーキンググループ以外で 開発される規格を、IANAで割り当てる値として予約される。この領域の 割り当てはIANAにより行われなければならない(MUST)。またフォーマルな 形で規定された圧縮方法が割り当てられなければならない(MUST)。 3. 193 (0xC1) から 255 (0xFF) までの領域は、私的利用目的として割り当て られる値とする。 圧縮方法の識別子の割り当てにおけるIANAの役割については、第5章を参照。 さらにこの定義をアップデートし、ZLIB圧縮方法を割り当てる。 enum { null(0), ZLIB(1), (255) } CompressionMethod; RFC2246 [2] の第6章で記述されているように、TLSはステータスの保持を行う プロトコルである。TLSで使用される圧縮方法は、ステータス保持を行うもの （圧縮データすべてを通じてステータスを保持するもの）でも保持を行わない もの（それぞれのデータを独立に圧縮するもの）でもよい。しかし、ステータス 保持を行わない圧縮方法をTLSで使用することのメリットについては知られて いないようである。 本ドキュメントで記述されているZLIB圧縮方法ではステータスの保持を行う。 将来において標準化される他の圧縮方法においても、ステータスの保持を行って いることが推奨される。 圧縮アルゴリズムでは、時には、入力データが圧縮されるのではなく拡張と なってもよい。しかしRFC2246 [2] の第6.2.2節で記述されている、拡張の 上限値を超えるような圧縮方法は、TLSでは使用してはならない(MUST NOT)。 2.1 圧縮の履歴とパケット処理 いくつかの圧縮方法では、パケットを圧縮または展開する際に、履歴情報を保持 することができる。圧縮の履歴情報を使用することにより、パケットごとに圧縮 するのに比べ、高い圧縮率を実現することができる。しかしパケット間を通して 履歴情報を保持することで、あるパケットでは、他のパケットに含まれている データを完全に展開するのに必要なデータを含んでいることが要求される。すな わち履歴情報の保持を行うには、信頼のおける通信リンクとシーケンシャルな パケット送信が必要である。TLSとその下位層プロトコルでは、信頼のおける、 シーケンシャルなパケット送信が行えるため、圧縮の履歴情報を保持してもよく (MAY)、もし圧縮方法でサポートしているならば履歴情報を利用してもよい(MAY)。 2.2 ZLIB 圧縮方法 ZLIB圧縮方法とエンコードフォーマットはRFC1950 [5] とRFC1951 [6] で記述 されている。ZLIBを使用している、IETFで規定されたプロトコルの例として、 RFC1979 [7]、RFC2394 [8]、RFC3274 [9] が挙げられる。 ZLIBでは、圧縮率、処理速度、必要メモリ量を変更するオプションを、データ 送信を行う圧縮側が選択することができる。そのデータを受信した展開側では、 送信者が選択したパラメータを自動で調整しなければならない(MUST)。圧縮 処理をするために入力されたすべてのデータは、圧縮された出力データに含ま れていなければならず(MUST)、すべてのデータは出力データのペイロード中 に保持されていてはならない。フラッシュ処理により、圧縮されたパケット のペイロードでは、完全な展開処理が可能となる。 3. 知的所有権に関する考察 圧縮アルゴリズムの多くは、特許やその他の知的所有権に関する権利が主張 されている。実装者は、本ドキュメント、またはTLSにおいて圧縮方法を使用 するための記述が行われている他のドキュメントで記述されている圧縮方法の 実装を開発することの意義をよりよく理解するための、法律的なガイダンスを さらに求めていくべきである。 4. 国際化に関する考察 本ドキュメントで規定している圧縮方法識別子は、機械で読むことが可能な 数値である。そのため、人間の世界における国際化や地域性に関する問題はない。 5. IANAに関する考慮事項 本ドキュメントの第2章では、IANAにより管理される圧縮方法識別子の登録や、 ZLIB圧縮方法の識別子の割り当てについて記述している。将来、TLSワーキング グループによる標準化のために予約されている範囲の識別子を割り当てる際には、 RFC2434 [3] で記述されている"Standards Action"ポリシーに基づいて割り当て られなければならない(MUST)。私的利用のために予約されている範囲の値は、 RFC2434で記述されている"Private Use"ポリシーに基づいて使用しなければ ならない(MUST)。IANA用に予約されている範囲の値は、RFC2434で記述されている "IETF Consensus"ポリシーに基づいて割り当てられなければならない(MUST)。 6. セキュリティに関する考察 本ドキュメントでは、TLSで述べられている脅威に代わるトピックについては 述べていない。RFC2246 [2] を通じて述べられているセキュリティに関する 考察は、本ドキュメントにも適用される。 しかし、圧縮方法と暗号処理を組み合わせた場合、圧縮をしない場合には隠蔽 されていた情報が漏洩することがある。圧縮前には同じ長さであった2つの データは、圧縮後に異なる長さになることがある。そのため、攻撃者は圧縮 されたデータ長を観察することで、圧縮前のデータに関する情報を引き出すこと ができる場合がある。さらに、いくつかの対称暗号スイートでは、暗号化した データのデータ長を隠蔽しない。他の対称暗号では、データ拡張を少し行うこと でデータ長の隠蔽を行うが、それでも完全に隠蔽しているわけではない。例えば、 パディングを行わないストリーム暗号を使用した暗号スイートでは、暗号化 するデータ長は隠蔽しない。CBCモードを使用しパディングを行う暗号スイート では、選択したパディング量に応じてデータ長を隠蔽する。TLSにおいて圧縮 方法を使用する際には、圧縮されたデータのデータ長は、圧縮されていない 元のデータのデータ長よりも、より多くの情報を提供する場合があることを考慮 に入れておくべきである(SHOULD)。 7. 謝辞 本ドキュメントで記述されている概念は、IETFのTLSワーキンググループメーリング リストにおいて2000年12月に議論されたものに基づいている。このときの議論に 貢献していただいたJeffrey Altman、Eric Rescorla、Marc Van Heyningen に感謝する。また本ドキュメントには、Tim Dierks、Pasi Eronen、Peter Gutmann、 Elgin Lee、Nikos Mavroyanopoulos、Alexey Melnikov、Bodo Moeller、Win Treese らによるその後の提案も含まれている。 参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 参考情報 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, . [5] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [6] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [7] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996. [8] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998. [9] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 著者のアドレス Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: shollenbeck@verisign.com 知的所有権 IETFは、本ドキュメントで記載されている技術の実装やその他の技術の使用 に対してクレームされている知的所有権またはその他の権利の効力または 適用範囲と、それらの権利に基づくすべてのライセンスが利用可もしくは 利用不可であるかに関して、どのような立場もとらない。これらに関しては、 すべての権利を明確にする努力が行われているわけではない。IETFの標準化 手順と標準化に関連したドキュメントに関する権利情報は、BCP-11より閲覧 することができる。公開され入手可能とされた権利のコピーや利用可能な ライセンスの保証、または本規定の実装者やユーザがそれらの所有権の一般 ライセンスもしくは使用許諾を得るための試みの結果は、IETF事務局から 得ることができる。 IETFでは、この標準規格を実装するために必要となる技術をカバーしている 著作権、特許もしくは特許申請、またはその他の知的所有権に関し、これらの 権利を持つパーティーからの情報提供を要請している。情報に関しては、 IETFのExecutive Directorに提出ください。 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. あとがき RFCの運営基金は現在、Internet Societyによって提供されている。 日本語訳 西原 啓輔 2003年12月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。