RFC 9850 - The SSLKEYLOGFILE Format for TLS 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9850.html
タイトル : RFC 9850 - TLS の SSLKEYLOGFILE 形式
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                        M. Thomson
Request for Comments: 9850                                       Mozilla
Category: Informational                                     Y. Rosomakho
ISSN: 2070-1721                                                  Zscaler
                                                           H. Tschofenig
                                                                   H-BRS
                                                               July 2026

The SSLKEYLOGFILE Format for TLS

TLS の SSLKEYLOGFILE 形式

Abstract

概要

This document describes a format that supports logging information about the secrets used in a TLS connection. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data.

このドキュメントでは、TLS 接続で使用されるシークレットに関するログ情報をサポートする形式について説明します。シークレットを SSLKEYLOGFILE 形式でファイルに記録すると、このファイルを使用して TLS エンドポイントによって交換されるメッセージを復号化する診断ツールとログツールが使用できるようになります。この形式は、TLS がテストデータのみを保護するシステムでの使用を目的としています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9850.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9850 で入手できます。

Copyright Notice

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンステキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。

   1.  Introduction
     1.1.  Applicability Statement
     1.2.  Conventions
   2.  The SSLKEYLOGFILE Format
     2.1.  Secret Labels for TLS 1.3
     2.2.  Secret Labels for TLS 1.2
     2.3.  Secret Labels for ECH
   3.  Security Considerations
   4.  IANA Considerations
     4.1.  SSLKEYLOGFILE Media Type
     4.2.  TLS SSLKEYLOGFILE Labels Registry
   5.  References
     5.1.  Normative References
     5.2.  Informative References
   Appendix A.  Example
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

Debugging or analyzing protocols can be challenging when TLS [TLS13] is used to protect the content of communications. Inspecting the content of encrypted messages in diagnostic tools can enable more thorough analysis.

通信のコンテンツを保護するために TLS [TLS13] が使用されている場合、プロトコルのデバッグや分析は困難になる可能性があります。診断ツールで暗号化されたメッセージの内容を検査すると、より徹底的な分析が可能になります。

Over time, multiple TLS implementations have informally adopted a file format for logging the secret values generated by the TLS key schedule. In many implementations, the file that the secrets are logged to is specified in an environment variable named "SSLKEYLOGFILE", hence the name of SSLKEYLOGFILE format. Note the use of "SSL" as this convention originally predates the adoption of TLS as the name of the protocol.

時間の経過とともに、複数の TLS 実装は、TLS キースケジュールによって生成されたシークレット値をログに記録するためのファイル形式を非公式に採用してきました。多くの実装では、シークレットが記録されるファイルは「SSLKEYLOGFILE」という名前の環境変数で指定されるため、SSLKEYLOGFILE 形式と呼ばれています。「SSL」の使用は、もともとこの規約がプロトコルの名前として TLS を採用する前に使用されたものであることに注意してください。

This document describes the SSLKEYLOGFILE format. This format can be used for TLS 1.2 [TLS12] and TLS 1.3 [TLS13]. The format also supports earlier TLS versions, though use of earlier versions is strongly discouraged [RFC8996] [RFC9325]. This format can also be used with DTLS [DTLS13], QUIC [RFC9000] [RFC9001], and other protocols that use the TLS key schedule. Use of this format could complement other protocol-specific logging such as qlog [QLOG].

このドキュメントでは、SSLKEYLOGFILE 形式について説明します。この形式は、TLS 1.2 [TLS12] および TLS 1.3 [TLS13] で使用できます。この形式は以前の TLS バージョンもサポートしていますが、以前のバージョンの使用は強く推奨されません [RFC8996] [RFC9325]。この形式は、DTLS [DTLS13]、QUIC [RFC9000] [RFC9001]、および TLS キースケジュールを使用するその他のプロトコルでも使用できます。この形式を使用すると、qlog [QLOG] などの他のプロトコル固有のログを補完できます。

This document also defines labels that can be used to log information about exchanges that use Encrypted Client Hello (ECH) [ECH].

この文書は、Encrypted Client Hello (ECH) [ECH] を使用する交換に関する情報をログに記録するために使用できるラベルも定義します。

1.1. Applicability Statement

1.1. 適用性に関する声明

The artifact that this document describes -- if made available to entities other than endpoints -- completely undermines the core guarantees that TLS provides. This format is intended for use in systems where TLS only protects test data. While the access that this information provides to TLS connections can be useful for diagnosing problems while developing systems, this mechanism MUST NOT be used in a production system. For software that is compiled, use of conditional compilation is the best way to ensure that deployed binaries cannot be configured to enable key logging.

このドキュメントで説明されているアーティファクトは、エンドポイント以外のエンティティに利用可能になった場合、TLS が提供する中核的な保証を完全に損なうことになります。この形式は、TLS がテストデータのみを保護するシステムでの使用を目的としています。この情報が TLS 接続に提供するアクセスは、システム開発中に問題を診断するのに役立ちますが、このメカニズムを運用システムで使用してはなりません。コンパイルされたソフトウェアの場合、デプロイされたバイナリがキーログを有効にするように構成されないようにするための最良の方法は、条件付きコンパイルの使用です。

Section 3 addresses a number of additional concerns that arise from the use of key logging.

セクション 3 では、キーロギングの使用から生じるその他の多くの懸念事項について説明します。

1.2. Conventions

1.2. 規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

2. The SSLKEYLOGFILE Format

2. SSLKEYLOGFILE 形式

A file in SSLKEYLOGFILE format is a text file. This document specifies the character encoding as UTF-8 [RFC3629]. Though the format itself only includes ASCII characters [RFC0020], comments MAY contain other characters. Though Unicode is permitted in comments, the file MUST NOT contain a Unicode byte order mark (U+FEFF).

SSLKEYLOGFILE 形式のファイルはテキストファイルです。この文書では文字エンコーディングを UTF-8 [RFC3629] として指定します。形式自体には ASCII 文字のみが含まれていますが [RFC0020]、コメントには他の文字が含まれていてもよい[MAY]。コメントでは Unicode が許可されていますが、ファイルには Unicode バイトオーダーマーク (U+FEFF) を含めてはなりません。

Lines are terminated using the line-ending convention of the platform on which the file is generated. Tools that process these files MUST accept CRLF (U+13 followed by U+10), CR (U+13), or LF (U+10) as a line terminator. Lines are ignored if they are empty or if the first character is an octothorpe character ('#', U+23). Other lines of the file each contain a single secret.

行は、ファイルが生成されるプラットフォームの行終了規則に従って終了されます。これらのファイルを処理するツールは、CRLF (U+13 の後に U+10)、CR (U+13)、または LF (U+10) を行終端記号として受け入れなければなりません。行が空の場合、または最初の文字が八角形文字 ('#'、U+23) の場合、行は無視されます。ファイルの他の行には、それぞれ 1 つのシークレットが含まれています。

Implementations that record secrets to a file do so continuously as those secrets are generated.

シークレットをファイルに記録する実装では、シークレットが生成されると継続的に記録が行われます。

Each secret is described using a single line composed of three values that are separated by a single space character (U+20). These values are:

各シークレットは、単一のスペース文字 (U+20) で区切られた 3 つの値で構成される 1 行を使用して記述されます。これらの値は次のとおりです。

label:

ラベル：

The label identifies the type of secret that is being conveyed; see Sections 2.1, 2.2, and 2.3 for descriptions of the labels that are defined in this document.

ラベルは、伝達される秘密のタイプを識別します。この文書で定義されているラベルの説明については、セクション 2.1、2.2、および 2.3 を参照してください。

client_random:

クライアントランダム:

The 32-byte value of the Random field from the ClientHello message that established the TLS connection. This value is encoded as 64 hexadecimal characters. In a log that can include secrets from multiple connections, this field can be used to identify a connection.

TLS 接続を確立した ClientHello メッセージの Random フィールドの 32 バイトの値。この値は 64 個の 16 進文字としてエンコードされます。複数の接続からのシークレットが含まれるログでは、このフィールドを使用して接続を識別できます。

secret:

秘密：

The value of the identified secret for the identified connection. This value is encoded in hexadecimal, with a length that depends on the size of the secret.

識別された接続の識別されたシークレットの値。この値は 16 進数でエンコードされ、長さはシークレットのサイズに応じて異なります。

For the hexadecimal values of client_random or secret, no convention exists for the case of characters "a" through "f" (or "A" through "F"). Files can be generated with either, so either form MUST be accepted when processing a file.

client_random または Secret の 16 進値については、文字「a」から「f」(または「A」から「F」) の大文字と小文字を区別する規則はありません。ファイルはどちらでも生成できるため、ファイルを処理するときはどちらの形式も受け入れなければなりません。

Diagnostic tools that accept files in this format might choose to ignore lines that do not conform to this format in the interest of ensuring that secrets can be obtained from corrupted files.

この形式のファイルを受け入れる診断ツールは、破損したファイルから確実にシークレットを取得できるようにするために、この形式に準拠していない行を無視することを選択する場合があります。

Logged secret values are not annotated with the cipher suite or other connection parameters. Therefore, a record of the TLS handshake might be needed to use the logged secrets.

ログに記録されたシークレット値には、暗号スイートやその他の接続パラメータの注釈は付けられません。したがって、ログに記録されたシークレットを使用するには、TLS ハンドシェイクの記録が必要になる場合があります。

2.1. Secret Labels for TLS 1.3

2.1. TLS 1.3のシークレットラベル

An implementation of TLS 1.3 produces a number of values as part of the key schedule (see Section 7.1 of [TLS13]). If ECH was successfully negotiated for a given connection, these labels MUST be followed by the value of the Random field from the Inner ClientHello. Otherwise, the Random field from the Outer ClientHello MUST be used.

TLS 1.3 の実装では、鍵スケジュールの一部として多数の値が生成されます ([TLS13] のセクション 7.1 を参照)。特定の接続に対して ECH のネゴシエーションが成功した場合、これらのラベルの後に、内部 ClientHello からの Random フィールドの値が続かなければなりません (MUST)。それ以外の場合は、外部 ClientHello の Random フィールドを使用する必要があります。

Each of the following labels correspond to the equivalent secret produced by the key schedule:

次の各ラベルは、キースケジュールによって生成される同等のシークレットに対応します。

CLIENT_EARLY_TRAFFIC_SECRET:

This secret is used to protect records sent by the client as early data, if early data is attempted by the client. Note that a server that rejects early data will not log this secret, though a client that attempts early data can do so unconditionally.

このシークレットは、クライアントが初期データを試行した場合に、クライアントによって初期データとして送信されたレコードを保護するために使用されます。初期データを拒否するサーバーはこのシークレットをログに記録しませんが、初期データを試行するクライアントは無条件に記録することができることに注意してください。

EARLY_EXPORTER_SECRET:

This secret is used for early exporters. Like CLIENT_EARLY_TRAFFIC_SECRET, this is only generated when early data is attempted and might not be logged by a server if early data is rejected.

このシークレットは初期のエクスポーターに使用されます。Like CLIENT_EARLY_TRAFFIC_SECRET, this is only generated when early data is attempted and might not be logged by a server if early data is rejected.

CLIENT_HANDSHAKE_TRAFFIC_SECRET:

This secret is used to protect handshake records sent by the client.

このシークレットは、クライアントによって送信されたハンドシェイクレコードを保護するために使用されます。

SERVER_HANDSHAKE_TRAFFIC_SECRET:

This secret is used to protect handshake records sent by the server.

このシークレットは、サーバーによって送信されたハンドシェイクレコードを保護するために使用されます。

CLIENT_TRAFFIC_SECRET_0:

This secret is used to protect application_data records sent by the client immediately after the handshake completes. This secret is identified as client_application_traffic_secret_0 in the TLS 1.3 key schedule.

このシークレットは、ハンドシェイクの完了直後にクライアントによって送信される application_data レコードを保護するために使用されます。このシークレットは、TLS 1.3 キースケジュールでは client_application_traffic_secret_0 として識別されます。

SERVER_TRAFFIC_SECRET_0:

This secret is used to protect application_data records sent by the server immediately after the handshake completes. This secret is identified as server_application_traffic_secret_0 in the TLS 1.3 key schedule.

このシークレットは、ハンドシェイクの完了直後にサーバーによって送信される application_data レコードを保護するために使用されます。このシークレットは、TLS 1.3 キースケジュールでは server_application_traffic_secret_0 として識別されます。

EXPORTER_SECRET:

エクスポーター_シークレット:

This secret is used in generating exporters (Section 7.5 of [TLS13]).

このシークレットはエクスポーターの生成に使用されます ([TLS13] のセクション 7.5)。

These labels all appear in uppercase in the key log, but they correspond to lowercase labels in the TLS key schedule (Section 7.1 of [TLS13]), except for the application data secrets as noted. For example, "EXPORTER_SECRET" in the log file corresponds to the secret named exporter_secret.

これらのラベルは、鍵ログではすべて大文字で表示されますが、前述のアプリケーションデータシークレットを除き、TLS 鍵スケジュール ([TLS13] のセクション 7.1) では小文字のラベルに対応します。たとえば、ログファイル内の「EXPORTER_SECRET」は、exporter_secret という名前のシークレットに対応します。

Note that the order that labels appear here corresponds to the order in which they are presented in [TLS13], but there is no guarantee that implementations will log secrets strictly in this order.

ここでラベルが表示される順序は、[TLS13] で表示される順序に対応しますが、実装が厳密にこの順序でシークレットをログに記録するという保証はないことに注意してください。

2.2. Secret Labels for TLS 1.2

2.2. TLS 1.2のシークレットラベル

Implementations of TLS 1.2 [TLS12] (and also earlier versions) use the label "CLIENT_RANDOM" to identify the "master" secret for the connection.

TLS 1.2 [TLS12] (およびそれ以前のバージョン) の実装では、ラベル「CLIENT_RANDOM」を使用して、接続の「マスター」シークレットを識別します。

2.3. Secret Labels for ECH

2.3. ECH の秘密ラベル

With ECH [ECH], additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public Key Encryption (HPKE) [HPKE]. A client can log the ECH labels described below if it offered ECH, regardless of server acceptance. The server can log the labels only if it successfully decrypted the ECH offered by the client, though it could choose to do so only when it accepts ECH.

ECH [ECH] では、ハイブリッド公開キー暗号化 (HPKE) [HPKE] を使用して内部 ClientHello メッセージを暗号化するためのハンドシェイク中に追加の秘密が導出されます。クライアントは、サーバーの受け入れに関係なく、ECH を提供した場合、以下で説明する ECH ラベルをログに記録できます。サーバーは、クライアントから提供された ECH を正常に復号化した場合にのみラベルをログに記録できますが、ECH を受け入れる場合にのみラベルをログに記録することを選択できます。

These labels MUST always use the Random from the Outer ClientHello.

これらのラベルは常に外側の ClientHello からのランダムを使用しなければなりません (MUST)。

ECH_SECRET:

This label corresponds to the Key Encapsulation Mechanism (KEM) shared secret used by HPKE (shared_secret in the algorithms in Section 5.1.1 of [HPKE]). The length of the secret is defined by the KEM negotiated for use with ECH.

このラベルは、HPKE によって使用される Key Encapsulation Mechanism (KEM) 共有秘密 ([HPKE] のセクション 5.1.1 のアルゴリズムのshared_secret) に対応します。シークレットの長さは、ECH で使用するためにネゴシエートされた KEM によって定義されます。

ECH_CONFIG:

The ECHConfig used to construct the ECH extension. The value is logged in hexadecimal representation.

ECH 拡張機能の構築に使用される ECHConfig。値は 16 進数表現で記録されます。

3. Security Considerations

3. セキュリティに関する考慮事項

Access to the content of a file in SSLKEYLOGFILE format allows an attacker to break the confidentiality and integrity protection on any TLS connections that are included in the file. This includes both active connections and connections for which encrypted records were previously stored. Therefore, ensuring adequate access control on these files becomes very important.

SSLKEYLOGFILE 形式のファイルのコンテンツにアクセスすると、攻撃者はファイルに含まれる TLS 接続の機密性と整合性の保護を破ることができます。これには、アクティブな接続と、暗号化されたレコードが以前に保存されていた接続の両方が含まれます。したがって、これらのファイルに対する適切なアクセス制御を確保することが非常に重要になります。

Implementations that support logging this data need to ensure that logging can only be enabled by those who are authorized. Allowing logging to be initiated by any entity that is not otherwise authorized to observe or modify the content of connections for which secrets are logged could represent a privilege escalation attack. Implementations that enable logging also need to ensure that access to logged secrets is limited, using appropriate file permissions or equivalent access control mechanisms.

このデータのログ記録をサポートする実装では、許可されたユーザーのみがログ記録を有効にできるようにする必要があります。シークレットが記録される接続の内容を観察または変更する権限を持たないエンティティによるログの開始を許可すると、特権昇格攻撃となる可能性があります。ログ記録を有効にする実装では、適切なファイル権限または同等のアクセス制御メカニズムを使用して、ログに記録されたシークレットへのアクセスが制限されていることを確認する必要もあります。

In order to support decryption, the secrets necessary to remove record protection are logged. However, as the keys that can be derived from these secrets are symmetric, an adversary with access to these secrets is also able to encrypt data for an active connection. This might allow for injection or modification of application data on a connection that would otherwise be protected by TLS.

復号化をサポートするために、記録保護を解除するために必要な秘密がログに記録されます。ただし、これらのシークレットから導出できるキーは対称であるため、これらのシークレットにアクセスできる攻撃者は、アクティブな接続のデータを暗号化することもできます。これにより、TLS によって保護されるはずの接続上でアプリケーションデータを挿入または変更できる可能性があります。

As some protocols rely on TLS for generating encryption keys, the SSLKEYLOGFILE format includes keys that identify the secret used in TLS exporters or early exporters (Section 7.5 of [TLS13]). Knowledge of these secrets can enable more than inspection or modification of encrypted data, depending on how an application protocol uses exporters. For instance, exporters might be used for session bindings (e.g., [RFC8471]), authentication (e.g., [RFC9261]), or other derived secrets that are used in application context. An adversary that obtains these secrets might be able to use this information to attack these applications. A TLS implementation might either choose to omit these secrets in contexts where the information might be abused or require separate authorization to enable logging of exporter secrets.

一部のプロトコルは暗号化キーの生成に TLS に依存しているため、SSLKEYLOGFILE 形式には、TLS エクスポーターまたは初期のエクスポーターで使用される秘密を識別するキーが含まれています ([TLS13] のセクション 7.5)。これらの秘密を知ることで、アプリケーションプロトコルがエクスポーターをどのように使用するかに応じて、暗号化されたデータの検査や変更以上のことが可能になります。たとえば、エクスポータは、セッションバインディング ([RFC8471] など)、認証 ([RFC9261] など)、またはアプリケーションコンテキストで使用されるその他の派生シークレットに使用される可能性があります。これらのシークレットを入手した攻撃者は、この情報を使用してこれらのアプリケーションを攻撃できる可能性があります。TLS 実装では、情報が悪用される可能性があるコンテキストではこれらのシークレットを省略することを選択するか、エクスポータシークレットのログを有効にするために別の承認を必要とするかのいずれかを選択する場合があります。

Using an environment variable, such as SSLKEYLOGFILE, to enable logging implies that access to the launch context for the application is needed to authorize logging. On systems that support specially named files, logs might be directed to these names so that logging does not result in storage but enables consumption by other programs. In both cases, applications might require special authorization or might rely on system-level access control to limit access to these capabilities.

SSLKEYLOGFILE などの環境変数を使用してロギングを有効にするということは、ロギングを許可するにはアプリケーションの起動コンテキストへのアクセスが必要であることを意味します。特別な名前のファイルをサポートするシステムでは、ログがストレージに残らないように、他のプログラムで使用できるように、ログがこれらの名前に送信される場合があります。どちらの場合も、アプリケーションには特別な許可が必要な場合や、システムレベルのアクセス制御に依存してこれらの機能へのアクセスを制限する場合があります。

Forward secrecy guarantees provided in TLS 1.3 (see Section 1.3 and Appendix F.1 of [TLS13]) and some modes of TLS 1.2 (such as those in Sections 2.1 and 2.2 of [RFC8422]) do not hold if key material is recorded. Access to key material allows an attacker to decrypt data exchanged in any previously logged TLS connections.

TLS 1.3 ([TLS13] のセクション 1.3 および付録 F.1 を参照) および TLS 1.2 の一部のモード ([RFC8422] のセクション 2.1 および 2.2 のモードなど) で提供される前方秘匿性の保証は、鍵素材が記録されている場合には適用されません。攻撃者はキーマテリアルにアクセスすると、以前に記録された TLS 接続で交換されたデータを復号化できます。

Logging the TLS 1.2 "master" secret provides the recipient of that secret far greater access to an active connection than TLS 1.3 secrets provide. In addition to reading and altering protected messages, the TLS 1.2 "master" secret confers the ability to resume the connection and impersonate either endpoint, insert records that result in renegotiation, and forge Finished messages. Implementations can avoid the risks associated with these capabilities by not logging this secret value.

TLS 1.2 の「マスター」シークレットをログに記録すると、そのシークレットの受信者は、TLS 1.3 シークレットが提供するよりもはるかに優れたアクティブな接続へのアクセスを提供します。TLS 1.2 の「マスター」シークレットは、保護されたメッセージの読み取りと変更に加えて、接続を再開していずれかのエンドポイントになりすまし、再ネゴシエーションを引き起こすレコードの挿入、および Finished メッセージの偽造を行う機能を付与します。実装では、このシークレット値をログに記録しないことで、これらの機能に関連するリスクを回避できます。

Access to the ECH_SECRET record in SSLKEYLOGFILE allows the attacker to decrypt the ECH extension and thereby reveal the content of the Inner ClientHello message, including the payload of the Server Name Indication (SNI) extension.

SSLKEYLOGFILE の ECH_SECRET レコードにアクセスすると、攻撃者は ECH 拡張機能を復号化し、それによって Server Name Indication (SNI) 拡張機能のペイロードを含む、Inner ClientHello メッセージの内容を明らかにすることができます。

Access to the HPKE-established shared secret used in ECH introduces a potential attack surface against the HPKE library since access to this keying material is normally not available otherwise.

ECH で使用される HPKE によって確立された共有秘密へのアクセスは、HPKE ライブラリに対する潜在的な攻撃対象領域をもたらします。これは、この鍵マテリアルへのアクセスは通常、他の方法では利用できないためです。

4. IANA Considerations

4. IANAの考慮事項

This document registers a media type (Section 4.1) and creates a registry for labels (Section 4.2).

この文書では、メディアタイプを登録し (セクション 4.1)、ラベルのレジストリを作成します (セクション 4.2)。

4.1. SSLKEYLOGFILE Media Type

4.1. SSLKEYLOGFILE メディアタイプ

The "application/sslkeylogfile" media type can be used to describe content in the SSLKEYLOGFILE format. IANA has added the following information to the "Media Types" registry at <https://www.iana.org/assignments/media-types>:

「application/sslkeylogfile」メディアタイプは、SSLKEYLOGFILE 形式でコンテンツを記述するために使用できます。IANA は、<https://www.iana.org/assignments/media-types> の「メディアタイプ」レジストリに次の情報を追加しました。

Type name:

型名:

application

応用

Subtype name:

サブタイプ名:

sslkeylogfile

Required parameters:

必須パラメータ:

N/A

該当なし

Optional parameters:

オプションのパラメータ:

N/A

該当なし

Encoding considerations:

エンコーディングに関する考慮事項:

UTF-8 without BOM, or ASCII only

BOM なしの UTF-8、または ASCII のみ

Security considerations:

セキュリティに関する考慮事項:

See Section 3.

セクション 3 を参照してください。

Interoperability considerations:

相互運用性に関する考慮事項:

Line endings might differ from platform convention.

行末はプラットフォームの規則と異なる場合があります。

Published specification:

公開された仕様:

RFC 9850

Applications that use this media type:

このメディアタイプを使用するアプリケーション:

Diagnostic and analysis tools that need to decrypt data that is otherwise protected by TLS.

TLS によって保護されているデータを復号化する必要がある診断および分析ツール。

Fragment identifier considerations:

フラグメント識別子の考慮事項:

N/A

該当なし

Additional information:

追加情報：

Deprecated alias names for this type:

このタイプの非推奨のエイリアス名:

N/A

該当なし

Magic number(s):

マジックナンバー:

N/A

該当なし

File extension(s):

ファイル拡張子:

N/A

該当なし

Macintosh file type code(s):

Macintosh ファイルタイプコード:

N/A

該当なし

Person & email address to contact for further information:

詳細についての連絡先の担当者と電子メールアドレス:

TLS WG (tls@ietf.org)

Intended usage:

使用目的:

COMMON

一般

Restrictions on usage:

使用上の制限:

N/A

該当なし

Author:

著者：

IETF TLS Working Group

IETF TLSワーキンググループ

Change controller:

コントローラーを変更します:

IETF

4.2. TLS SSLKEYLOGFILE Labels Registry

4.2. TLS SSLKEYLOGFILE ラベルレジストリ

IANA has created a new registry named "TLS SSLKEYLOGFILE Labels" within the existing "Transport Layer Security (TLS) Parameters" registry group. This new registry reserves labels used for SSLKEYLOGFILE entries. The initial contents of this registry are as follows:

IANA は、既存の「Transport Layer Security (TLS) Parameters」レジストリグループ内に「TLS SSLKEYLOGFILE Labels」という名前の新しいレジストリを作成しました。この新しいレジストリは、SSLKEYLOGFILE エントリに使用されるラベルを予約します。このレジストリの初期内容は次のとおりです。

+=================================+=====================+===========+
| Value                           | Description         | Reference |
+=================================+=====================+===========+
| CLIENT_RANDOM                   | Master secret in    | RFC 9850  |
|                                 | TLS 1.2 and         |           |
|                                 | earlier             |           |
+---------------------------------+---------------------+-----------+
| CLIENT_EARLY_TRAFFIC_SECRET     | Secret for client   | RFC 9850  |
|                                 | early data          |           |
|                                 | records             |           |
+---------------------------------+---------------------+-----------+
| EARLY_EXPORTER_SECRET           | Early exporter      | RFC 9850  |
|                                 | secret              |           |
+---------------------------------+---------------------+-----------+
| CLIENT_HANDSHAKE_TRAFFIC_SECRET | Secret protecting   | RFC 9850  |
|                                 | client handshake    |           |
+---------------------------------+---------------------+-----------+
| SERVER_HANDSHAKE_TRAFFIC_SECRET | Secret protecting   | RFC 9850  |
|                                 | server handshake    |           |
+---------------------------------+---------------------+-----------+
| CLIENT_TRAFFIC_SECRET_0         | Secret protecting   | RFC 9850  |
|                                 | client records      |           |
|                                 | post handshake      |           |
+---------------------------------+---------------------+-----------+
| SERVER_TRAFFIC_SECRET_0         | Secret protecting   | RFC 9850  |
|                                 | server records      |           |
|                                 | post handshake      |           |
+---------------------------------+---------------------+-----------+
| EXPORTER_SECRET                 | Exporter secret     | RFC 9850  |
|                                 | after handshake     |           |
+---------------------------------+---------------------+-----------+
| ECH_SECRET                      | HPKE KEM shared     | RFC 9850  |
|                                 | secret used in      |           |
|                                 | the ECH             |           |
+---------------------------------+---------------------+-----------+
| ECH_CONFIG                      | ECHConfig used      | RFC 9850  |
|                                 | for construction    |           |
|                                 | of the ECH          |           |
+---------------------------------+---------------------+-----------+

                               Table 1

New assignments in the "TLS SSLKEYLOGFILE Labels" registry will be administered by IANA through the Specification Required procedure [RFC8126]. The role of designated experts for TLS registries is described in Section 17 of [RFC8447]. Designated experts for this registry are advised to ensure that the specification is publicly available. In the Reference column, it is sufficient to cite an Internet-Draft (that is posted but not published as an RFC) or a document from another standards body, an industry consortium, or any other organization. Designated experts may provide more in-depth reviews, but their approval should not be taken as an endorsement of the SSLKEYLOGFILE label.

「TLS SSLKEYLOGFILE Labels」レジストリ内の新しい割り当ては、仕様要求手順 [RFC8126] を通じて IANA によって管理されます。TLS レジストリの指定専門家の役割は、[RFC8447] のセクション 17 に説明されています。このレジストリに指定された専門家は、仕様が確実に公開されるようにすることをお勧めします。「参考文献」列では、インターネットドラフト (投稿されているが RFC として公開されていない)、または別の標準化団体、業界コンソーシアム、またはその他の組織からの文書を引用するだけで十分です。指定された専門家がより詳細なレビューを提供する場合がありますが、その承認を SSLKEYLOGFILE ラベルの承認とみなすべきではありません。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

   [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
              March 2026, <https://www.rfc-editor.org/info/rfc9849>.

   [HPKE]     Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/info/rfc9180>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [TLS12]    Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/info/rfc9846>.

5.2. Informative References

5.2. 参考引用

   [DTLS13]   Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.

   [QLOG]     Marx, R., Ed., Niccolini, L., Ed., Seemann, M., Ed., and
              L. Pardue, Ed., "qlog: Structured Logging for Network
              Protocols", Work in Progress, Internet-Draft, draft-ietf-
              quic-qlog-main-schema-14, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              qlog-main-schema-14>.

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC20, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8422]  Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
              Curve Cryptography (ECC) Cipher Suites for Transport Layer
              Security (TLS) Versions 1.2 and Earlier", RFC 8422,
              DOI 10.17487/RFC8422, August 2018,
              <https://www.rfc-editor.org/info/rfc8422>.

   [RFC8447]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
              and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
              <https://www.rfc-editor.org/info/rfc8447>.

   [RFC8471]  Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges,
              "The Token Binding Protocol Version 1.0", RFC 8471,
              DOI 10.17487/RFC8471, October 2018,
              <https://www.rfc-editor.org/info/rfc8471>.

   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
              "Handling Long Lines in Content of Internet-Drafts and
              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
              <https://www.rfc-editor.org/info/rfc8792>.

   [RFC8996]  Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
              <https://www.rfc-editor.org/info/rfc8996>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/info/rfc9001>.

   [RFC9261]  Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
              DOI 10.17487/RFC9261, July 2022,
              <https://www.rfc-editor.org/info/rfc9261>.

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

Appendix A. Example

付録A. 例

The following is a sample of a file in SSLKEYLOGFILE format, including secrets from two TLS 1.3 connections.

以下は、2 つの TLS 1.3 接続からのシークレットを含む、SSLKEYLOGFILE 形式のファイルのサンプルです。

The examples below use line wrapping per [RFC8792].

以下の例では、[RFC8792] に従って行折り返しを使用しています。

   CLIENT_HANDSHAKE_TRAFFIC_SECRET \
     cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
     be4a28d81ce41242ff31c6d8a6615852178f2cd75eaca2ee8768f9ed51282b38
   SERVER_HANDSHAKE_TRAFFIC_SECRET \
     cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
     258179721fa704e2f1ee16688b4b0419967ddea5624cd5ad0863288dc5ead35f
   CLIENT_HANDSHAKE_TRAFFIC_SECRET \
     b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \
     59ec0981b211a743f22d5a46a1fc77a2b230e16ef0de6d4e418abfe90eff10bf
   SERVER_HANDSHAKE_TRAFFIC_SECRET \
     b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \
     a37fe4d3b6c9a6a372396b1562f6f8a40c1c3f85f1aa9b02d5ed46c4a1301365
   CLIENT_TRAFFIC_SECRET_0 \
     cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
     e9ca165bcb762fab8086068929d26c532e90ef2e2daa762d8b52346951a34c02
   SERVER_TRAFFIC_SECRET_0 \
     cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
     4f93c61ac1393008d4c820f3723db3c67494f06574b65fcc21c9eef22f90071a
   EXPORTER_SECRET \
     cf34899b3dcb8c9fe7160ceaf95d354a294793b67a2e49cb9cca4d69b43593a0 \
     011c900833468f837f7c55d836b2719beebd39b1648fdeda58772f48d94a1ffa
   CLIENT_TRAFFIC_SECRET_0 \
     b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \
     e9160bca1a531d871f5ecf51943d8cfb88833adeccf97701546b5fb93e030d79
   SERVER_TRAFFIC_SECRET_0 \
     b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \
     fb1120b91e48d402fac20faa33880e77bace82c85d6688df0aa99bf5084430e4
   EXPORTER_SECRET \
     b2eb93b8ddab8c228993567947bca1e133736980c22754687874e3896f7d6d0a \
     db1f4fa1a6942fb125d4cc47e02938b6f8030c6956bb81b9e3269f1cf855a8f8

Note that secrets from the two connections might be interleaved as shown here, because secrets could be logged as they are generated.

シークレットは生成時にログに記録される可能性があるため、2 つの接続からのシークレットはここに示すようにインターリーブされる可能性があることに注意してください。

The following shows a log entry for a TLS 1.2 connection.

以下に、TLS 1.2 接続のログエントリを示します。

   CLIENT_RANDOM \
     ad52329fcadd34ee3aa07092680287f09954823e26d7b5ae25c0d47714152a6a \
     97af4c8618cfdc0b2326e590114c2ec04b43b08b7e2c3f8124cc61a3b068ba966\
     9517e744e3117c3ce6c538a2d88dfdf

The following shows a log entry for a TLS 1.3 connection that successfully negotiated ECH.

以下は、ECH のネゴシエーションに成功した TLS 1.3 接続のログエントリを示しています。

   ECH_SECRET \
     0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \
     e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a
   ECH_CONFIG \
     0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \
     fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d59 \
     4e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000
   CLIENT_HANDSHAKE_TRAFFIC_SECRET \
     8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
     a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140
   SERVER_HANDSHAKE_TRAFFIC_SECRET \
     8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
     022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c
   CLIENT_TRAFFIC_SECRET_0 \
     8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
     c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172
   SERVER_TRAFFIC_SECRET_0 \
     8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
     04ffc7c154f71ba5f530c7344b0496f60ce71b9b7c6b0e203ea574bfcdf14e27
   EXPORTER_SECRET \
     8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \
     befb5db5ac6785b5dd4c6a8c4693c379ec0a1486b5fd035b25e50c3c95abc500

Acknowledgments

謝辞

The SSLKEYLOGFILE format originated in the Network Security Services (NSS) project, but it has evolved over time as TLS has changed. Many people contributed to this evolution. The authors are only documenting the format as it is used while extending it to cover ECH.

SSLKEYLOGFILE 形式は Network Security Services (NSS) プロジェクトで誕生しましたが、TLS の変化に応じて時間の経過とともに進化してきました。多くの人々がこの進化に貢献しました。著者は、ECH をカバーするためにフォーマットを拡張しながら、使用されているフォーマットを文書化しているだけです。

Authors' Addresses

著者の住所

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net

   Yaroslav Rosomakho
   Zscaler
   Email: yrosomakho@zscaler.com

   Hannes Tschofenig
   University of Applied Sciences Bonn-Rhein-Sieg
   Email: Hannes.Tschofenig@gmx.net

RFC 9850 - The SSLKEYLOGFILE Format for TLS 日本語訳

The SSLKEYLOGFILE Format for TLS

TLS の SSLKEYLOGFILE 形式

Abstract

概要

Status of This Memo

本文書の状態

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

1.1. Applicability Statement

1.1. 適用性に関する声明

1.2. Conventions

1.2. 規約

2. The SSLKEYLOGFILE Format

2. SSLKEYLOGFILE 形式

2.1. Secret Labels for TLS 1.3

2.1. TLS 1.3のシークレットラベル

2.2. Secret Labels for TLS 1.2

2.2. TLS 1.2のシークレットラベル

2.3. Secret Labels for ECH

2.3. ECH の秘密ラベル

3. Security Considerations

3. セキュリティに関する考慮事項

4. IANA Considerations

4. IANAの考慮事項

4.1. SSLKEYLOGFILE Media Type

4.1. SSLKEYLOGFILE メディア タイプ

4.2. TLS SSLKEYLOGFILE Labels Registry

4.2. TLS SSLKEYLOGFILE ラベル レジストリ

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

5.2. Informative References

5.2. 参考引用

Appendix A. Example

付録A. 例

Acknowledgments

謝辞

Authors' Addresses

著者の住所

4.1. SSLKEYLOGFILE メディアタイプ

4.2. TLS SSLKEYLOGFILE ラベルレジストリ