[要約] RFC 8672は、TLSサーバーの識別ピニングをチケットと組み合わせて行うための仕様です。その目的は、セキュリティを向上させ、中間者攻撃や偽装サーバーによる攻撃を防ぐことです。
Independent Submission Y. Sheffer
Request for Comments: 8672 Intuit
Category: Experimental D. Migault
ISSN: 2070-1721 Ericsson
October 2019
TLS Server Identity Pinning with Tickets
チケットによるTLSサーバーIDの固定
Abstract
概要
Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.
発行された公開鍵証明書は、TLSクライアントがTLSサーバーを適切に認証することを妨げる可能性があります。この状況を検出し、クライアントが不正な公開鍵証明書で認証されたTLSエンドポイントとのTLSセッションを確立できないようにするために、いくつかの代替案が提案されています。これらのメカニズムは、広く展開されていないか、パブリックWebブラウジングに限定されていません。
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.
このドキュメントでは、サーバーのIDを固定する方法として、不透明な固定チケットを使用したTLSの実験的な拡張を提案しています。最初のTLSセッション中に、サーバーは元の暗号化された固定チケットを提供します。その後のTLSセッションの確立では、ピン留めチケットを受信すると、サーバーはピン留めチケットを解読する能力、つまりピン留め保護キーの所有権を証明します。これで、クライアントは、TLSセッションが元のTLSセッションと同じTLSサーバーで確立されたと安全に結論付けることができます。この提案の重要な特性の1つは、手動の管理アクションが必要ないことです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8672.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8672で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Conventions Used in This Document
1.2. Scope of Experimentation
2. Protocol Overview
2.1. Initial Connection
2.2. Subsequent Connections
2.3. Indexing the Pins
3. Message Definitions
4. Cryptographic Operations
4.1. Pinning Secret
4.2. Pinning Ticket
4.3. Pinning Protection Key
4.4. Pinning Proof
5. Operational Considerations
5.1. Protection Key Synchronization
5.2. Ticket Lifetime
5.3. Certificate Renewal
5.4. Certificate Revocation
5.5. Disabling Pinning
5.6. Server Compromise
5.7. Disaster Recovery
6. Security Considerations
6.1. Trust-on-First-Use (TOFU) and MITM Attacks
6.2. Pervasive Monitoring
6.3. Server-Side Error Detection
6.4. Client Policy and SSL Proxies
6.5. Client-Side Error Behavior
6.6. Stolen and Forged Tickets
6.7. Client Privacy
6.8. Ticket Protection Key Management
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Previous Work
A.1. Comparison: HPKP
A.2. Comparison: TACK
Acknowledgments
Authors' Addresses
Misissued public-key certificates can prevent TLS [RFC8446] clients from appropriately authenticating the TLS server. This is a significant risk in the context of the global public key infrastructure (PKI), and similarly for large-scale deployments of certificates within enterprises.
発行された公開鍵証明書は、TLS [RFC8446]クライアントがTLSサーバーを適切に認証することを妨げる可能性があります。これは、グローバル公開キーインフラストラクチャ（PKI）のコンテキストでは重要なリスクであり、企業内での証明書の大規模な展開でも同様です。
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. The approach is intended to be easy to implement and deploy, and reuses some of the ideas behind TLS session resumption [RFC5077].
このドキュメントでは、サーバーのIDを固定する方法として、不透明な固定チケットを使用したTLSの実験的な拡張を提案しています。このアプローチは、実装と展開が簡単であることが意図されており、TLSセッション再開の背後にあるいくつかのアイデアを再利用します[RFC5077]。
Ticket pinning is a second-factor server authentication method and is not proposed as a substitute for the authentication method provided in the TLS key exchange. More specifically, the client only uses the pinning identity method after the TLS key exchange is successfully completed. In other words, the pinning identity method is only performed over an authenticated TLS session. Note that ticket pinning does not pin certificate information and therefore is truly an independent second-factor authentication.
チケットのピン留めは第2要素のサーバー認証方法であり、TLSキー交換で提供される認証方法の代わりとして提案されていません。具体的には、クライアントは、TLS鍵交換が正常に完了した後でのみ、ピン留めアイデンティティ方式を使用します。つまり、ピン留めアイデンティティ方式は、認証されたTLSセッションでのみ実行されます。チケット固定は証明書情報を固定しないため、真に独立した第2要素認証であることに注意してください。
Ticket pinning is a trust-on-first-use (TOFU) mechanism, in that the first server authentication is only based on PKI certificate validation, but for any follow-on sessions, the client is further ensuring the server's identity based on the server's ability to decrypt the ticket, in addition to normal PKI certificate authentication.
チケットのピン留めは、最初のサーバー認証がPKI証明書の検証にのみ基づくという点で、最初の使用を信頼する（TOFU）メカニズムですが、その後のセッションでは、クライアントはサーバーのIDに基づいてサーバーのIDをさらに保証します通常のPKI証明書認証に加えて、チケットを復号化する機能。
During initial TLS session establishment, the client requests a pinning ticket from the server. Upon receiving the request the server generates a pinning secret that is expected to be unpredictable for peers other than the client or the server. In our case, the pinning secret is generated from parameters exchanged during the TLS key exchange, so client and server can generate it locally and independently. The server constructs the pinning ticket with the necessary information to retrieve the pinning secret. The server then encrypts the ticket and returns the pinning ticket to the client with an associated pinning lifetime.
最初のTLSセッションの確立中に、クライアントはサーバーに固定チケットを要求します。リクエストを受信すると、サーバーは、クライアントまたはサーバー以外のピアには予測不可能であると予想されるピン留めシークレットを生成します。今回のケースでは、ピン留めシークレットはTLS鍵交換中に交換されるパラメーターから生成されるため、クライアントとサーバーはローカルおよび独立してそれを生成できます。サーバーは、ピン留めシークレットを取得するために必要な情報を含むピン留めチケットを作成します。次に、サーバーはチケットを暗号化し、関連付けられた固定存続期間とともに固定チケットをクライアントに返します。
The pinning lifetime value indicates for how long the server promises to retain the server-side ticket-encryption key, which allows it to complete the protocol exchange correctly and prove its identity. The server commitment (and ticket lifetime) is typically on the order of weeks.
ピニングライフタイム値は、サーバーがサーバー側のチケット暗号化キーを保持することを約束する期間を示します。これにより、プロトコル交換を正しく完了し、そのIDを証明できます。サーバーのコミットメント（およびチケットの有効期間）は通常、数週間程度です。
Once the key exchange is completed, and the server is deemed authenticated, the client generates locally the pinning secret and caches the server's identifiers to index the pinning secret as well as the pinning ticket and its associated lifetime.
鍵交換が完了し、サーバーが認証されたと見なされると、クライアントはローカルでピン留めシークレットを生成し、サーバーの識別子をキャッシュして、ピン留めシークレットとピン留めチケットとそれに関連する有効期間をインデックス化します。
When the client reestablishes a new TLS session with the server, it sends the pinning ticket to the server. Upon receiving it, the server returns a proof of knowledge of the pinning secret. Once the key exchange is completed, and the server has been authenticated, the client checks the pinning proof returned by the server using the client's stored pinning secret. If the proof matches, the client can conclude that the server to which it is currently connecting is, in fact, the correct server.
クライアントがサーバーとの新しいTLSセッションを再確立すると、固定チケットをサーバーに送信します。それを受信すると、サーバーはピン留め秘密の知識の証明を返します。鍵の交換が完了し、サーバーが認証されると、クライアントは、サーバーに返された固定証明を、クライアントに保存されている固定秘密を使用して確認します。証明が一致する場合、クライアントは、現在接続しているサーバーが実際には正しいサーバーであると結論付けることができます。
This document only applies to TLS 1.3. We believe that the idea can also be retrofitted into earlier versions of the protocol, but this would require significant changes. One example is that TLS 1.2 [RFC5246] and earlier versions do not provide a generic facility of encrypted handshake extensions, such as is used here to transport the ticket.
このドキュメントはTLS 1.3にのみ適用されます。このアイデアは、プロトコルの以前のバージョンにも組み込むことができると考えていますが、これには大幅な変更が必要になります。一例として、TLS 1.2 [RFC5246]以前のバージョンでは、ここでチケットの転送に使用されるような、暗号化されたハンドシェイク拡張の汎用機能が提供されていません。
The main advantages of this protocol over earlier pinning solutions are the following:
以前の固定ソリューションに対するこのプロトコルの主な利点は次のとおりです。
* The protocol is at the TLS level, and as a result is not restricted to HTTP at the application level.
* プロトコルはTLSレベルであり、その結果、アプリケーションレベルでHTTPに制限されません。
* The protocol is robust to changes in server IP address, certification authority (CA), and public key. The server is characterized by the ownership of the pinning protection key, which is never provided to the client. Server configuration parameters such as the CA and the public key may change without affecting the pinning ticket protocol.
* このプロトコルは、サーバーのIPアドレス、証明機関（CA）、および公開キーの変更に対して堅牢です。サーバーは、クライアントに提供されることのない固定保護キーの所有権によって特徴付けられます。 CAや公開キーなどのサーバー構成パラメーターは、ピン留めチケットプロトコルに影響を与えることなく変更できます。
* Once a single parameter is configured (the ticket's lifetime), operation is fully automated. The server administrator need not bother with the management of backup certificates or explicit pins.
* 単一のパラメーター（チケットの有効期間）が構成されると、操作は完全に自動化されます。サーバー管理者は、バックアップ証明書や明示的なピンの管理に煩わされる必要はありません。
* For server clusters, we reuse the existing infrastructure [RFC5077] where it exists.
* サーバークラスタの場合、既存のインフラストラクチャ[RFC5077]が存在する場合は、それを再利用します。
* Pinning errors, presumably resulting from man-in-the-middle (MITM) attacks, can be detected both by the client and the server. This allows for server-side detection of MITM attacks using large-scale analytics, and with no need to rely on clients to explicitly report the error.
* おそらく中間者（MITM）攻撃に起因する固定エラーは、クライアントとサーバーの両方で検出できます。これにより、大規模な分析を使用してMITM攻撃のサーバー側での検出が可能になり、クライアントに依存してエラーを明示的に報告する必要がなくなります。
A note on terminology: unlike other solutions in this space, we do not do "certificate pinning" (or "public key pinning"), since the protocol is oblivious to the server's certificate. We prefer the term "server identity pinning" for this new solution. In our solution, the server proves its identity by generating a proof that it can read and decrypt an encrypted ticket. As a result, the identity proof relies on proof of ownership of the pinning protection key. However, this key is never exchanged with the client or known by it, and so cannot itself be pinned.
用語に関する注記：この分野の他のソリューションとは異なり、プロトコルはサーバーの証明書に気づかないため、「証明書の固定」（または「公開鍵の固定」）は行いません。この新しいソリューションでは、「サーバーIDの固定」という用語を使用します。私たちのソリューションでは、サーバーは、暗号化されたチケットを読み取って復号化できることの証明を生成することにより、その身元を証明します。その結果、IDの証明は、固定保護キーの所有権の証明に依存しています。ただし、このキーはクライアントと交換されたり、クライアントによって認識されたりすることはないため、それ自体を固定することはできません。
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]で説明されているように解釈されます。
This document describes an experimental extension to the TLS protocol. This section defines constraints on this experiment and how it can yield useful information, potentially resulting in a standard.
このドキュメントでは、TLSプロトコルの実験的な拡張について説明します。このセクションでは、この実験の制約と、実験がどのようにして有用な情報を生み出し、標準になる可能性があるかを定義します。
The protocol is designed so that if the server does not support it, the client and server fall back to a normal TLS exchange, with the exception of a single PinningTicket extension being initially sent by the client. In addition, the protocol is designed only to strengthen the validation of the server's identity ("second factor"). As a result, implementation or even protocol errors should not result in weakened security compared to the normal TLS exchange. Given these two points, experimentation can be run on the open Internet between consenting client and server implementations.
プロトコルは、サーバーがそれをサポートしない場合、クライアントによって最初に送信される単一のPinningTicket拡張を除いて、クライアントとサーバーが通常のTLS交換にフォールバックするように設計されています。さらに、このプロトコルは、サーバーのID（「第2要素」）の検証を強化するためにのみ設計されています。その結果、実装エラーやプロトコルエラーでさえ、通常のTLS交換と比較してセキュリティが低下することはありません。これらの2つの点を考慮すると、クライアントとサーバーの同意の実装の間で、オープンインターネット上で実験を実行できます。
The goal of the experiment is to prove that:
実験の目的は、次のことを証明することです。
* Non-supporting clients and servers are unaffected.
* サポートされていないクライアントとサーバーは影響を受けません。
* Connectivity between supporting clients and servers is retained under normal circumstances, whether the client connects to the server frequently (relative to the ticket's lifetime) or very rarely.
* サポートするクライアントとサーバー間の接続は、クライアントがサーバーに頻繁に（チケットの存続期間に関連して）接続するか、ごくまれに接続するかに関係なく、通常の状況で保持されます。
* Enterprise middleboxes do not interrupt such connectivity.
* エンタープライズミドルボックスは、このような接続を中断しません。
* Misissued certificates and rogue TLS-aware middleboxes do result in broken connectivity, and these cases are detected on the client and/or server side. Clients and servers can be recovered even after such events and the normal connectivity restored.
* 誤って発行された証明書と不正なTLS対応ミドルボックスは接続が切断され、これらのケースはクライアント側またはサーバー側、あるいはその両方で検出されます。このようなイベントや通常の接続が復元された後でも、クライアントとサーバーを回復できます。
Following two years of successful deployment, the authors will publish a document that summarizes the experiment's findings and will resubmit the protocol for consideration as a Proposed Standard.
2年間の展開に成功した後、著者は実験の結果をまとめたドキュメントを公開し、提案された標準として検討するためにプロトコルを再提出します。
The protocol consists of two phases: the first time a particular client connects to a server, and subsequent connections.
プロトコルは2つのフェーズで構成されます。特定のクライアントがサーバーに初めて接続するときと、その後の接続です。
This protocol supports full TLS handshakes, as well as 0-RTT handshakes. Below we present it in the context of a full handshake, but behavior in 0-RTT handshakes should be identical.
このプロトコルは、完全なTLSハンドシェイクと0-RTTハンドシェイクをサポートしています。以下では、完全なハンドシェイクのコンテキストでそれを提示しますが、0-RTTハンドシェイクの動作は同じでなければなりません。
The document presents some similarities with the ticket resumption mechanism described in [RFC5077]. However the scope of this document differs from session resumption mechanisms implemented with [RFC5077] or with other mechanisms. Specifically, the pinning ticket does not carry any state associated with a TLS session and thus cannot be used for session resumption or client authentication. Instead, the pinning ticket only contains the encrypted pinning secret. The pinning ticket is used by the server to prove its ability to decrypt it, which implies ownership of the pinning protection key.
このドキュメントは、[RFC5077]で説明されているチケット再開メカニズムといくつかの類似点を示しています。ただし、このドキュメントの範囲は、[RFC5077]または他のメカニズムで実装されたセッション再開メカニズムとは異なります。具体的には、ピン留めチケットはTLSセッションに関連付けられた状態を持たないため、セッションの再開やクライアント認証には使用できません。代わりに、固定チケットには暗号化された固定シークレットのみが含まれています。サーバーは、ピン留めチケットを使用してそれを解読する能力を証明します。これは、ピン留め保護キーの所有権を意味します。
[RFC5077] has been obsoleted by [RFC8446], and ticket resumption is now defined by Section 2.2 of [RFC8446]. This document references [RFC5077] as an informational document since it contains a more thorough discussion of stateless ticket resumption, and because ticket resumption benefits from significant operational experience with TLS 1.2 that is still widely deployed at the time of writing. This experience, as well as deployment experience, can easily be re-used for identity pinning.
[RFC5077]は[RFC8446]で廃止され、チケットの再開は[RFC8446]のセクション2.2で定義されるようになりました。このドキュメントは、ステートレスチケットの再開に関するより詳細な説明が含まれており、チケットの再開は、執筆時にまだ広く展開されているTLS 1.2の重要な運用経験から恩恵を受けるため、情報ドキュメントとして[RFC5077]を参照します。このエクスペリエンスと展開エクスペリエンスは、IDの固定に簡単に再利用できます。
With TLS 1.3, session resumption is based on a Pre-Shared Key (PSK). This is orthogonal to this protocol. With TLS 1.3, a TLS session can be established using PKI and a pinning ticket, and later resumed with PSK.
TLS 1.3では、セッションの再開は事前共有キー（PSK）に基づいています。これは、このプロトコルに直交しています。 TLS 1.3では、PKIとピンチケットを使用してTLSセッションを確立し、後でPSKで再開できます。
However, the protocol described in this document addresses the problem of misissued certificates. Thus, it is not expected to be used outside a certificate-based TLS key exchange, such as in PSK. As a result, PSK handshakes MUST NOT include the extension defined here.
ただし、このドキュメントで説明されているプロトコルは、誤って発行された証明書の問題に対処します。したがって、PSKなどの証明書ベースのTLS鍵交換以外では使用しないでください。その結果、PSKハンドシェイクには、ここで定義された拡張を含めてはなりません（MUST NOT）。
When a client first connects to a server, it requests a pinning ticket by sending an empty PinningTicket extension, and receives it as part of the server's first response, in the returned PinningTicket extension.
クライアントが最初にサーバーに接続するとき、クライアントは空のPinningTicket拡張機能を送信してピン留めチケットを要求し、サーバーの最初の応答の一部として、返されたPinningTicket拡張機能でそれを受信します。
Client Server
クライアントサーバー
ClientHello
+ key_share
+ signature_algorithms
+ PinningTicket -------->
ServerHello
+ key_share
{EncryptedExtensions
+ PinningTicket}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
<-------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
* Indicates optional or situation-dependent messages that are not always sent.
* 常に送信されるわけではないオプションのメッセージまたは状況依存のメッセージを示します。
{} Indicates messages protected using keys derived from the ephemeral secret.
{}短命の秘密から派生したキーを使用して保護されたメッセージを示します。
[] Indicates messages protected using keys derived from the master secret.
[]マスターシークレットから派生したキーを使用して保護されたメッセージを示します。
If a client supports the PinningTicket extension and does not have any pinning ticket associated with the server, the exchange is considered as an initial connection. Other reasons the client may not have a pinning ticket include the client having flushed its pinning ticket store, or the committed lifetime of the pinning ticket having expired.
クライアントがPinningTicket拡張をサポートしていて、サーバーに関連付けられている固定チケットがない場合、交換は初期接続と見なされます。クライアントがピンチケットを持っていないその他の理由には、クライアントがピンチケットストアをフラッシュしたか、ピンチケットのコミットされた有効期限が切れたなどがあります。
Upon receipt of the PinningTicket extension, the server computes a pinning secret (Section 4.1) and sends the pinning ticket (Section 4.2) encrypted with the pinning protection key (Section 4.3). The pinning ticket is associated with a lifetime value by which the server assumes the responsibility of retaining the pinning protection key and being able to decrypt incoming pinning tickets during the period indicated by the committed lifetime.
サーバーは、PinningTicket拡張を受信すると、固定シークレット（セクション4.1）を計算し、固定保護キー（セクション4.3）で暗号化された固定チケット（セクション4.2）を送信します。ピンチケットは、サーバーがピン保護キーを保持し、コミットされたライフタイムで示される期間中に着信ピンチケットを復号化できる責任を負うライフタイム値に関連付けられています。
Once the pinning ticket has been generated, the server returns the pinning ticket and the committed lifetime in a PinningTicket extension embedded in the EncryptedExtensions message. We note that a PinningTicket extension MUST NOT be sent as part of a HelloRetryRequest.
ピンチケットが生成されると、サーバーはピンチケットとコミットされた有効期間をEncryptedExtensionsメッセージに埋め込まれたPinningTicket拡張で返します。 PinningTicket拡張は、HelloRetryRequestの一部として送信してはならないことに注意してください。
Upon receiving the pinning ticket, the client MUST NOT accept it until the key exchange is completed and the server authenticated. If the key exchange is not completed successfully, the client MUST ignore the received pinning ticket. Otherwise, the client computes the pinning secret and SHOULD cache the pinning secret and the pinning ticket for the duration indicated by the pinning ticket lifetime. The client SHOULD clean up the cached values at the end of the indicated lifetime.
固定チケットを受け取ったクライアントは、鍵交換が完了してサーバーが認証されるまで、それを受け入れてはなりません（MUST NOT）。鍵交換が正常に完了しない場合、クライアントは受信したピン留めチケットを無視する必要があります。それ以外の場合、クライアントはピン留めシークレットを計算し、ピン留めチケットの有効期間で示される期間、ピン留めシークレットとピン留めチケットをキャッシュする必要があります。クライアントは、示された有効期間の終わりにキャッシュされた値をクリーンアップする必要があります（SHOULD）。
When the client initiates a connection to a server it has previously seen (see Section 2.3 on identifying servers), it SHOULD send the pinning ticket for that server. The pinning ticket, pinning secret, and pinning ticket lifetime computed during the establishment of the previous TLS session are designated in this document as the "original" ones, to distinguish them from a new ticket that may be generated during the current session.
クライアントが以前に確認したサーバーへの接続を開始すると（サーバーの識別についてはセクション2.3を参照）、そのサーバーの固定チケットを送信する必要があります（SHOULD）。このドキュメントでは、以前のTLSセッションの確立中に計算されたピン留めチケット、ピン留めシークレット、およびピン留めチケットの有効期間を「オリジナル」として指定し、現在のセッション中に生成される可能性のある新しいチケットと区別します。
The server MUST extract the original pinning_secret value from the ticket and MUST respond with a PinningTicket extension, which includes:
サーバーはチケットから元のpinning_secret値を抽出する必要があり、以下を含むPinningTicket拡張で応答する必要があります。
* A proof that the server can understand the ticket that was sent by the client; this proof also binds the pinning ticket to the server's (current) public key, as well as the ongoing TLS session. The proof is mandatory and MUST be included if a pinning ticket was sent by the client.
* サーバーがクライアントから送信されたチケットを理解できることの証明。この証明は、ピン留めチケットをサーバーの（現在の）公開鍵と、進行中のTLSセッションにバインドします。証明は必須であり、ピン留めチケットがクライアントによって送信された場合は含める必要があります。
* A fresh pinning ticket. The main reason for refreshing the ticket on each connection is privacy: to avoid the ticket serving as a fixed client identifier. While a fresh pinning ticket might be of zero length, it is RECOMMENDED to include a fresh ticket with a nonzero length with each response.
* 新鮮な固定チケット。各接続でチケットを更新する主な理由はプライバシーです。チケットが固定クライアント識別子として機能しないようにするためです。新しいピン留めチケットは長さがゼロの場合がありますが、応答ごとに長さがゼロ以外の新しいチケットを含めることをお勧めします。
If the server cannot validate the received ticket, that might indicate an earlier MITM attack on this client. The server MUST then abort the connection with a handshake_failure alert and SHOULD log this failure.
サーバーが受信したチケットを検証できない場合は、このクライアントに対する以前のMITM攻撃を示している可能性があります。次に、サーバーはhandshake_failureアラートで接続を中止し、この失敗をログに記録する必要があります（SHOULD）。
The client MUST verify the proof, and if it fails to do so, the client MUST issue a handshake_failure alert and abort the connection (see also Section 6.5). It is important that the client does not attempt to "fall back" by omitting the PinningTicket extension.
クライアントは証明を検証する必要があり、検証に失敗した場合、クライアントはhandshake_failureアラートを発行して接続を中止する必要があります（セクション6.5も参照）。クライアントがPinningTicket拡張機能を省略して「フォールバック」を試みないことが重要です。
When the connection is successfully set up, i.e., after the Finished message is verified, the client SHOULD store the new ticket along with the corresponding pinning_secret, replacing the original ticket.
接続が正常にセットアップされると、つまり、Finishedメッセージが検証された後、クライアントは、対応するpinning_secretとともに新しいチケットを格納して、元のチケットを置き換える必要があります（SHOULD）。
Although this is an extension, if the client already has a ticket for a server, the client MUST interpret a missing PinningTicket extension in the server's response as an attack, because of the server's prior commitment to respect the ticket. The client MUST abort the connection in this case. See also Section 5.5 on ramping down support for this extension.
これは拡張機能ですが、クライアントがサーバーのチケットをすでに持っている場合、サーバーはチケットを尊重するという事前のコミットメントのため、クライアントはサーバーの応答に欠落しているPinningTicket拡張機能を攻撃として解釈する必要があります。この場合、クライアントは接続を中止する必要があります。この拡張機能のサポートのランプダウンについては、セクション5.5も参照してください。
Each pin is associated with a set of identifiers that include, among others, hostname, protocol (TLS or DTLS), and port number. In other words, the pin for port TCP/443 may be different from that for DTLS, or from the pin for port TCP/8443. These identifiers are expected to be relevant to characterize the identity of the server as well as the establishing TLS session. When a hostname is used, it MUST be the value sent inside the Server Name Indication (SNI) extension. This definition is similar to the concept of a Web Origin [RFC6454], but does not assume the existence of a URL.
各ピンは、ホスト名、プロトコル（TLSまたはDTLS）、ポート番号などの識別子のセットに関連付けられています。つまり、ポートTCP / 443のピンは、DTLSのピンまたはポートTCP / 8443のピンとは異なる場合があります。これらの識別子は、サーバーのIDと確立中のTLSセッションを特徴付けるために関連していると予想されます。ホスト名が使用される場合、それはサーバー名表示（SNI）拡張内で送信される値でなければなりません。この定義はWeb Origin [RFC6454]の概念に似ていますが、URLの存在を想定していません。
The purpose of ticket pinning is to pin the server identity. As a result, any information orthogonal to the server's identity MUST NOT be considered in indexing. More particularly, IP addresses are ephemeral and forbidden in SNI, and therefore pins MUST NOT be associated with IP addresses. Similarly, CA names or public keys associated with server MUST NOT be used for indexing as they may change over time.
チケット固定の目的は、サーバーIDを固定することです。その結果、サーバーのIDに直交する情報は、インデックス作成で考慮してはなりません。より具体的には、IPアドレスは一時的でSNIで禁止されているため、ピンをIPアドレスに関連付けることはできません。同様に、サーバーに関連付けられたCA名または公開鍵は、時間の経過とともに変化する可能性があるため、インデックス作成に使用してはなりません（MUST NOT）。
This section defines the format of the PinningTicket extension. We follow the message notation of [RFC8446].
このセクションでは、PinningTicket拡張の形式を定義します。 [RFC8446]のメッセージ表記に従います。
opaque pinning_ticket<0..2^16-1>;
opaque pinning_proof<0..2^8-1>;
struct {
select (Role) {
case client:
pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection
case server:
pinning_proof proof<0..2^8-1>; //no proof on 1st connection
pinning_ticket ticket<0..2^16-1>; //omitted on ramp down
uint32 lifetime;
}
} PinningTicketExtension;
ticket a pinning ticket sent by the client or returned by the server. The ticket is opaque to the client. The extension MUST contain exactly 0 or 1 tickets.
チケットクライアントから送信された、またはサーバーから返されたピン留めチケット。チケットはクライアントに対して不透明です。エクステンションは正確に0または1チケットを含む必要があります。
proof a demonstration by the server that it understands the received ticket and therefore that it is in possession of the secret that was used to generate it originally. The extension MUST contain exactly 0 or 1 proofs.
サーバーが受け取ったチケットを理解し、それによって元々チケットを生成するために使用された秘密を保持していることをサーバーが証明することを証明します。拡張には、0または1の証明が正確に含まれている必要があります。
lifetime the duration (in seconds) that the server commits to accept offered tickets in the future.
サーバーが将来提供されるチケットを受け入れることをコミットする期間（秒単位）。
This section provides details on the cryptographic operations performed by the protocol peers.
このセクションでは、プロトコルピアによって実行される暗号化操作の詳細について説明します。
The pinning secret is generated locally by the client and the server, which means they must use the same inputs to generate it. This value must be generated before the ServerHello message is sent, as the server includes the corresponding pinning ticket in the same flight as the ServerHello message. In addition, the pinning secret must be unpredictable to any party other than the client and the server.
ピン留めシークレットはクライアントとサーバーによってローカルに生成されます。つまり、ピン留めシークレットは同じ入力を使用して生成する必要があります。サーバーはServerHelloメッセージと同じフライトに対応するピン留めチケットを含めるため、この値はServerHelloメッセージが送信される前に生成する必要があります。さらに、ピン留めシークレットは、クライアントとサーバー以外の関係者には予測できないものでなければなりません。
The pinning secret is derived using the Derive-Secret function provided by TLS 1.3, described in Section 7.1 of [RFC8446].
[RFC8446]のセクション7.1で説明されているように、TLS 1.3が提供するDerive-Secret関数を使用して、ピン留めシークレットが導出されます。
pinning secret = Derive-Secret(Handshake Secret, "pinning secret", ClientHello...ServerHello)
pinning secret = Derive-Secret（Handshake Secret、 "pinning secret"、ClientHello ... ServerHello）
The pinning ticket contains the pinning secret. The pinning ticket is provided by the client to the server, which decrypts it in order to extract the pinning secret and responds with a pinning proof. As a result, the characteristics of the pinning ticket are:
固定チケットには固定シークレットが含まれています。固定チケットはクライアントからサーバーに提供され、サーバーはそれを解読して固定秘密を抽出し、固定証明で応答します。その結果、固定チケットの特徴は次のとおりです。
* Pinning tickets MUST be encrypted and integrity-protected using strong cryptographic algorithms.
* 固定チケットは、強力な暗号アルゴリズムを使用して暗号化し、整合性を保護する必要があります。
* Pinning tickets MUST be protected with a long-term pinning protection key.
* 固定チケットは、長期固定保護キーで保護する必要があります。
* Pinning tickets MUST include a pinning protection key ID or serial number as to enable the pinning protection key to be refreshed.
* 固定チケットには、固定保護キーを更新できるように、固定保護キーIDまたはシリアル番号を含める必要があります。
* The pinning ticket MAY include other information, in addition to the pinning secret. When additional information is included, a careful review needs to be performed to evaluate its impact on privacy.
* 固定チケットには、固定の秘密に加えて他の情報が含まれる場合があります。追加情報が含まれている場合、プライバシーへの影響を評価するために注意深いレビューを実行する必要があります。
The pinning ticket's format is not specified by this document, but a format similar to the one proposed by [RFC5077] is RECOMMENDED.
ピニングチケットの形式はこのドキュメントでは指定されていませんが、[RFC5077]で提案されている形式と同様の形式が推奨されます。
The pinning protection key is used only by the server and so remains server implementation specific. [RFC5077] recommends the use of two keys, but when using Authenticated Encryption with Associated Data (AEAD) algorithms, only a single key is required.
ピン保護キーはサーバーでのみ使用されるため、サーバーの実装に固有のままです。 [RFC5077]は2つのキーの使用を推奨していますが、関連データを使用した認証暗号化（AEAD）アルゴリズムを使用する場合、必要なキーは1つだけです。
When a single server terminates TLS for multiple virtual servers using the SNI mechanism, it is strongly RECOMMENDED that the server use a separate protection key for each one of them, in order to allow migrating virtual servers between different servers while keeping pinning active.
単一のサーバーがSNIメカニズムを使用して複数の仮想サーバーのTLSを終了する場合、ピン留めをアクティブに保ちながら異なるサーバー間で仮想サーバーを移行できるようにするために、サーバーはそれぞれに個別の保護キーを使用することを強くお勧めします。
As noted in Section 5.1, if the server is actually a cluster of machines, the protection key MUST be synchronized between all the nodes that accept TLS connections to the same server name. When [RFC5077] is deployed, an easy way to do it is to derive the protection key from the session-ticket protection key, which is already synchronized. For example:
セクション5.1で述べたように、サーバーが実際にマシンのクラスターである場合は、同じサーバー名へのTLS接続を受け入れるすべてのノード間で保護キーを同期する必要があります。 [RFC5077]が展開されている場合、それを行う簡単な方法は、すでに同期されているセッションチケット保護キーから保護キーを取得することです。例えば：
pinning_protection_key = HKDF-Expand(resumption_protection_key, "pinning protection", L)
pinning_protection_key = HKDF-Expand（resumption_protection_key、 "pinning protection"、L）
Where resumption_protection_key is the ticket protection key defined in [RFC5077]. Both resumption_protection_key and pinning_protection_key are only used by the server.
ここで、resumption_protection_keyは、[RFC5077]で定義されているチケット保護キーです。 resumption_protection_keyとpinning_protection_keyはどちらもサーバーでのみ使用されます。
The above solution attempts to minimize code changes related to management of the resumption_protection_key. The drawback is that this key would be used both to directly encrypt session tickets and to derive the pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices. Where possible, it is RECOMMENDED that the resumption_protection_key be unrelated to the pinning_protection_key and that they are separately shared among the relevant servers.
上記のソリューションでは、resumption_protection_keyの管理に関連するコードの変更を最小限に抑えようとしています。欠点は、このキーがセッションチケットを直接暗号化するためとpinning_protection_keyを導出するための両方に使用され、単一のキーのこのような混合使用が暗号化のベストプラクティスに沿っていないことです。可能な場合、resumption_protection_keyがpinning_protection_keyと無関係であり、それらが関連するサーバー間で個別に共有されることが推奨されます。
The pinning proof is sent by the server to demonstrate that it has been able to decrypt the pinning ticket and to retrieve the pinning secret. The proof must be unpredictable and must not be replayed. Similarly to the pinning ticket, the pinning proof is sent by the server in the ServerHello message. In addition, it must not be possible for a MITM server with a fake certificate to obtain a pinning proof from the original server.
サーバーは、ピン留め証明を送信して、ピン留めチケットを復号化し、ピン留めシークレットを取得できたことを示します。証明は予測不可能であり、再生することはできません。固定チケットと同様に、固定プルーフはServerHelloメッセージでサーバーから送信されます。さらに、偽の証明書を持つMITMサーバーが元のサーバーからピン留め証明を取得することはできません。
In order to address these requirements, the pinning proof is bound to the TLS session as well as the public key of the server:
これらの要件に対処するために、ピン留め証明はTLSセッションとサーバーの公開鍵にバインドされています。
pinning_proof_secret=Derive-Secret(Handshake Secret, "pinning proof 1", ClientHello...ServerHello)
pinning_proof_secret = Derive-Secret（Handshake Secret、 "pinning proof 1"、ClientHello ... ServerHello）
proof = HMAC(original_pinning_secret, "pinning proof 2" +
pinning_proof_secret + Hash(server_public_key))
where HMAC [RFC2104] uses the Hash algorithm that was negotiated in the handshake, and the same hash is also used over the server's public key. The original_pinning_secret value refers to the secret value extracted from the ticket sent by the client, to distinguish it from a new pinning secret value that is possibly computed in the current exchange. The server_public_key value is the DER representation of the public key, specifically the SubjectPublicKeyInfo structure as-is.
ここで、HMAC [RFC2104]はハンドシェイクでネゴシエートされたハッシュアルゴリズムを使用し、同じハッシュがサーバーの公開鍵でも使用されます。 original_pinning_secret値は、クライアントによって送信されたチケットから抽出された秘密値を参照して、現在の交換で計算される可能性のある新しいピン留め秘密値と区別します。 server_public_keyの値は、公開鍵のDER表現であり、具体的には、SubjectPublicKeyInfo構造がそのままです。
The main motivation behind the current protocol is to enable identity pinning without the need for manual operations. Manual operations are susceptible to human error, and in the case of public key pinning, can easily result in "server bricking": the server becoming inaccessible to some or all of its users. To achieve this goal, operations described in identity pinning are only performed within the current TLS session, and there is no dependence on any TLS configuration parameters such as CA identity or public keys. As a result, configuration changes are unlikely to lead to desynchronized state between the client and the server.
現在のプロトコルの主な動機は、手動操作を必要とせずにIDピン留めを有効にすることです。手動操作は人為的ミスの影響を受けやすく、公開鍵のピン留めの場合、「サーバーのブリック」が発生しやすく、サーバーの一部またはすべてのユーザーがサーバーにアクセスできなくなります。この目標を達成するために、IDピン留めで説明されている操作は現在のTLSセッション内でのみ実行され、CA IDや公開キーなどのTLS構成パラメーターに依存しません。その結果、構成を変更しても、クライアントとサーバーの間で非同期状態が発生することはほとんどありません。
The only operational requirement when deploying this protocol is that, if the server is part of a cluster, protection keys (the keys used to encrypt tickets) MUST be synchronized between all cluster members. The protocol is designed so that if resumption ticket protection keys [RFC5077] are already synchronized between cluster members, nothing more needs to be done.
このプロトコルをデプロイする場合の唯一の運用要件は、サーバーがクラスターの一部である場合、すべてのクラスターメンバー間で保護キー（チケットの暗号化に使用されるキー）を同期する必要があることです。プロトコルは、再開チケット保護キー[RFC5077]がクラスターメンバー間ですでに同期されている場合、これ以上行う必要がないように設計されています。
Moreover, synchronization does not need to be instantaneous, e.g., protection keys can be distributed a few minutes or hours in advance of their rollover. In such scenarios, each cluster member MUST be able to accept tickets protected with a new version of the protection key, even while it is still using an old version to generate keys. This ensures that, when a client receives a "new" ticket, it does not next hit a cluster member that still rejects this ticket.
さらに、同期は瞬時である必要はありません。たとえば、保護キーは、ロールオーバーの数分または数時間前に配布できます。このようなシナリオでは、各クラスターメンバーは、古いバージョンを使用してキーを生成している場合でも、新しいバージョンの保護キーで保護されたチケットを受け入れる必要があります。これにより、クライアントが「新しい」チケットを受信したときに、このチケットを拒否しているクラスターメンバーを次にヒットすることがなくなります。
Misconfiguration can lead to the server's clock being off by a large amount of time. Consider a case where a server's clock is misconfigured, for example, to be 1 year in the future, and the system is allowed to delete expired keys automatically. The server will then delete many outstanding keys because they are now long expired and will end up rejecting valid tickets that are stored by clients. Such a scenario could make the server inaccessible to a large number of clients.
設定を誤ると、サーバーのクロックが大幅にずれることがあります。サーバーのクロックが誤って構成されている場合（たとえば、1年後）になり、システムが期限切れのキーを自動的に削除することが許可されている場合を考えます。その後、サーバーは多くの未処理のキーを削除します。これは、これらのキーの有効期限が長くなり、クライアントによって保存されている有効なチケットが拒否されることになるためです。このようなシナリオでは、多数のクライアントがサーバーにアクセスできなくなる可能性があります。
The decision to delete a key should at least consider the largest value of the ticket lifetime as well as the expected time desynchronization between the servers of the cluster and the time difference for distributing the new key among the different servers in the cluster.
キーを削除する決定では、チケットの有効期間の最大値と、クラスターのサーバー間で予想される非同期化、およびクラスター内の異なるサーバー間で新しいキーを配布するための時間差を少なくとも考慮する必要があります。
The lifetime of the ticket is a commitment by the server to retain the ticket's corresponding protection key for this duration, so that the server can prove to the client that it knows the secret embedded in the ticket. For production systems, the lifetime SHOULD be between 7 and 31 days.
チケットの有効期間は、サーバーがチケットの対応する保護キーをこの期間保持するというコミットメントであり、サーバーは、チケットに埋め込まれた秘密を知っていることをクライアントに証明できます。本番システムの場合、存続期間は7〜31日である必要があります。
The protocol ensures that the client will continue speaking to the correct server even when the server's certificate is renewed. In this sense, pinning is not associated with certificates, which is the reason we designate the protocol described in this document as "server identity pinning".
このプロトコルにより、サーバーの証明書が更新された場合でも、クライアントは引き続き正しいサーバーと通信します。この意味で、ピン留めは証明書に関連付けられていないため、このドキュメントで説明されているプロトコルを「サーバーIDのピン留め」と指定しています。
Note that this property is not impacted by the use of the server's public key in the pinning proof because the scope of the public key used is only the current TLS session.
使用される公開鍵のスコープは現在のTLSセッションのみであるため、このプロパティはピン留め証明でのサーバーの公開鍵の使用による影響を受けないことに注意してください。
The protocol is orthogonal to certificate validation in the sense that, if the server's certificate has been revoked or is invalid for some other reason, the client MUST refuse to connect to it regardless of any ticket-related behavior.
プロトコルは、サーバーの証明書が失効しているか、その他の理由で無効である場合、クライアントはチケット関連の動作に関係なく、サーバーへの接続を拒否する必要があるという意味で、証明書の検証と直交しています。
A server implementing this protocol MUST have a "ramp down" mode of operation where:
このプロトコルを実装するサーバーは、「ランプダウン」動作モードが必要です。
* The server continues to accept valid pinning tickets and responds correctly with a proof.
* サーバーは引き続き有効なピン留めチケットを受け入れ、証明で正しく応答します。
* The server does not send back a new pinning ticket.
* サーバーは新しい固定チケットを送り返しません。
After a while, no clients will hold valid tickets, and the feature may be disabled. Note that clients that do not receive a new pinning ticket do not necessarily need to remove the original ticket. Instead, the client may keep using the ticket until its lifetime expires. However, as detailed in Section 6.7, re-use of a ticket by the client may result in privacy concerns as the ticket value may be used to correlate TLS sessions.
しばらくすると、有効なチケットを保持するクライアントがなくなり、機能が無効になる場合があります。新しい固定チケットを受信しないクライアントは、必ずしも元のチケットを削除する必要がないことに注意してください。代わりに、クライアントはその有効期限が切れるまでチケットを使い続けます。ただし、セクション6.7で詳述されているように、チケット値はTLSセッションの相関に使用される可能性があるため、クライアントによるチケットの再利用はプライバシーの問題を引き起こす可能性があります。
Issuing a new pinning ticket with a shorter lifetime would only delay the ramp down process, as the shorter lifetime can only affect clients that actually initiated a new connection. Other clients would still see the original lifetime for their pinning tickets.
短い有効期間は実際に新しい接続を開始したクライアントにのみ影響するため、有効期間が短い新しいピン留めチケットを発行しても、ランプダウンプロセスが遅延するだけです。他のクライアントには、ピン留めチケットの元の有効期間が表示されます。
If a server compromise is detected, the pinning protection key MUST be rotated immediately, but the server MUST still accept valid tickets that use the old, compromised key. Clients that still hold old pinning tickets will remain vulnerable to MITM attacks, but those that connect to the correct server will immediately receive new tickets protected with the newly generated pinning protection key.
サーバーの侵害が検出された場合、固定保護キーは直ちにローテーションする必要がありますが、サーバーは古い、侵害されたキーを使用する有効なチケットを受け入れる必要があります。古いピン留めチケットを保持しているクライアントはMITM攻撃に対して脆弱なままですが、正しいサーバーに接続するクライアントは、新しく生成されたピン留め保護キーで保護された新しいチケットをすぐに受け取ります。
The same procedure applies if the pinning protection key is compromised directly, e.g., if a backup copy is inadvertently made public.
バックアップコピーが誤って公開された場合など、固定保護キーが直接侵害された場合も同じ手順が適用されます。
All web servers in production need to be backed up, so that they can be recovered if a disaster (including a malicious activity) ever wipes them out. Backup often includes the certificate and its private key, which must be backed up securely. The pinning secret, including earlier versions that are still being accepted, must be backed up regularly. However since it is only used as an authentication second factor, it does not require the same level of confidentiality as the server's private key.
運用中のすべてのWebサーバーはバックアップする必要があります。これにより、災害（悪意のあるアクティビティを含む）によって完全に一掃された場合に回復できるようになります。多くの場合、バックアップには証明書とその秘密キーが含まれます。これらは安全にバックアップする必要があります。まだ受け入れられている以前のバージョンを含め、ピン留めの秘密は定期的にバックアップする必要があります。ただし、認証の第2要素としてのみ使用されるため、サーバーの秘密鍵と同じレベルの機密性は必要ありません。
Readers should note that [RFC5077] session resumption keys are more security sensitive and should normally not be backed up, but rather treated as ephemeral keys. Even when servers derive pinning secrets from resumption keys (Section 4.1), they MUST NOT back up resumption keys.
読者は、[RFC5077]セッション再開キーの方がセキュリティに敏感であり、通常はバックアップせず、一時的なキーとして扱う必要があることに注意してください。サーバーが再開キーからピンシークレットを導出する場合でも（セクション4.1）、再開キーをバックアップしてはなりません（MUST NOT）。
This section reviews several security aspects related to the proposed extension.
このセクションでは、提案された拡張機能に関連するいくつかのセキュリティの側面を確認します。
This protocol is a trust-on-first-use protocol. If a client initially connects to the "right" server, it will be protected against MITM attackers for the lifetime of each received ticket. If it connects regularly (depending, of course, on the server-selected lifetime), it will stay constantly protected against fake certificates.
このプロトコルは、最初に使用する信頼プロトコルです。クライアントが最初に「正しい」サーバーに接続する場合、受信した各チケットの存続期間中、MITM攻撃者から保護されます。定期的に接続する場合（もちろん、サーバーが選択したライフタイムに依存します）、偽の証明書から常に保護されます。
However if it initially connects to an attacker, subsequent connections to the "right" server will fail. Server operators might want to advise clients on how to remove corrupted pins, once such large-scale attacks are detected and remediated.
ただし、最初に攻撃者に接続した場合、その後の「正しい」サーバーへの接続は失敗します。サーバーオペレーターは、このような大規模な攻撃が検出されて修復されたら、破損したピンを削除する方法についてクライアントにアドバイスすることができます。
The protocol is designed so that it is not vulnerable to an active MITM attacker who has real-time access to the original server. The pinning proof includes a hash of the server's public key to ensure the client that the proof was in fact generated by the server with which it is initiating the connection.
このプロトコルは、元のサーバーにリアルタイムでアクセスできるアクティブなMITM攻撃者に対して脆弱にならないように設計されています。固定証明には、サーバーの公開鍵のハッシュが含まれ、クライアントが接続を開始しているサーバーによって実際に証明が生成されたことを確認します。
Some organizations, and even some countries, perform pervasive monitoring on their constituents [RFC7258]. This often takes the form of always-active SSL proxies. Because of the TOFU property, this protocol does not provide any security in such cases.
一部の組織、さらには一部の国では、その構成要素に対して広汎な監視を行っています[RFC7258]。多くの場合、これは常にアクティブなSSLプロキシの形式をとります。 TOFUプロパティのため、このプロトコルはそのような場合にはセキュリティを提供しません。
Pervasive monitoring may also result in privacy concerns detailed in Section 6.7.
広範にわたる監視は、セクション6.7に詳述されているプライバシーの問題を引き起こす可能性もあります。
Uniquely, this protocol allows the server to detect clients that present incorrect tickets and therefore can be assumed to be victims of a MITM attack. Server operators can use such cases as indications of ongoing attacks, similarly to fake certificate attacks that took place in a few countries in the past.
ユニークなことに、このプロトコルにより、サーバーは不正なチケットを提示するクライアントを検出できるため、MITM攻撃の被害者であると見なすことができます。サーバーオペレーターは、過去数か国で行われた偽の証明書攻撃と同様に、進行中の攻撃の兆候などのケースを使用できます。
Like it or not, some clients are normally deployed behind an SSL proxy. Similar to [RFC7469], it is acceptable to allow pinning to be disabled for some hosts according to local policy. For example, a User Agent (UA) MAY disable pinning for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built into the UA (or underlying platform). Moreover, a client MAY accept an empty PinningTicket extension from such hosts as a valid response.
好むと好まざるとにかかわらず、一部のクライアントは通常、SSLプロキシの背後に配置されます。 [RFC7469]と同様に、一部のホストでは、ローカルポリシーに従ってピン留めを無効にできます。たとえば、ユーザーエージェント（UA）は、検証された証明書チェーンが、UA（または基盤となるプラットフォーム）に組み込まれたトラストアンカーではなく、ユーザー定義のトラストアンカーで終了するホストのピン留めを無効にする場合があります。さらに、クライアントはそのようなホストからの空のPinningTicket拡張を有効な応答として受け入れることができます（MAY）。
When a client receives a malformed or empty PinningTicket extension from a pinned server, it MUST abort the handshake. If the client retries the request, it MUST NOT omit the PinningTicket in the retry message. Doing otherwise would expose the client to trivial fallback attacks, similar to those described in [RFC7507].
クライアントがピン留めされたサーバーから不正な形式または空のPinningTicket拡張を受信すると、ハンドシェイクを中止する必要があります。クライアントがリクエストを再試行する場合、再試行メッセージでPinningTicketを省略してはなりません（MUST NOT）。それ以外の場合は、[RFC7507]で説明されているのと同様に、クライアントを簡単なフォールバック攻撃にさらすことになります。
However, this rule can negatively impact clients that move from behind SSL proxies into the open Internet, and vice versa, if the advice in Section 6.4 is not followed. Therefore, it is RECOMMENDED that browser and library vendors provide a documented way to remove stored pins.
ただし、このルールは、セクション6.4のアドバイスに従わない場合、SSLプロキシの背後からオープンインターネットに、またはその逆に移動するクライアントに悪影響を与える可能性があります。したがって、ブラウザとライブラリのベンダーが、保存されたピンを削除するための文書化された方法を提供することが推奨されます。
An attacker gains no benefit from stealing pinning tickets, even in conjunction with other pinning parameters such as the associated pinning secret, since pinning tickets are used to secure the client rather than the server. Similarly, it is useless to forge a ticket for a particular server.
固定チケットはサーバーではなくクライアントを保護するために使用されるため、関連する固定シークレットなどの他の固定パラメーターと組み合わせても、攻撃者は固定チケットを盗むことによるメリットはありません。同様に、特定のサーバーのチケットを偽造しても意味がありません。
This protocol is designed so that an external attacker cannot link different requests to a single client, provided the client requests and receives a fresh ticket upon each connection. This may be of concern particularly during ramp down, if the server does not provide a new ticket, and the client reuses the same ticket. To reduce or avoid such privacy concerns, it is RECOMMENDED for the server to issue a fresh ticket with a reduced lifetime. This would at least reduce the time period in which the TLS sessions of the client can be linked. The server MAY also issue tickets with a zero-second lifetime until it is confident all tickets are expired.
このプロトコルは、クライアントがリクエストし、接続ごとに新しいチケットを受信する場合、外部の攻撃者が単一のクライアントに異なるリクエストをリンクできないように設計されています。これは、サーバーが新しいチケットを提供せず、クライアントが同じチケットを再利用する場合、特にランプダウン中に問題になる可能性があります。このようなプライバシーの問題を軽減または回避するために、サーバーで有効期間を短くして新しいチケットを発行することをお勧めします。これにより、少なくともクライアントのTLSセッションをリンクできる期間が短縮されます。サーバーはまた、すべてのチケットが期限切れであると確信するまで、ゼロ秒のライフタイムでチケットを発行する場合があります。
On the other hand, the server to which the client is connecting can easily track the client. This may be an issue when the client expects to connect to the server (e.g., a mail server) with multiple identities. Implementations SHOULD allow the user to opt out of pinning, either in general or for particular servers.
一方、クライアントが接続しているサーバーは、クライアントを簡単に追跡できます。これは、クライアントが複数のIDを使用してサーバー（メールサーバーなど）に接続することを期待している場合に問題になる可能性があります。実装では、一般的にまたは特定のサーバーに対して、ユーザーが固定をオプトアウトできるようにする必要があります（SHOULD）。
This document does not define the exact content of tickets. Including client-specific information in tickets would raise privacy concerns and is NOT RECOMMENDED.
このドキュメントでは、チケットの正確な内容を定義していません。チケットにクライアント固有の情報を含めると、プライバシーの問題が発生するため、お勧めしません。
While the ticket format is not mandated by this document, protecting the ticket using authenticated encryption is RECOMMENDED. Some of the algorithms commonly used for authenticated encryption, e.g., Galois/Counter Mode (GCM), are highly vulnerable to nonce reuse, and this problem is magnified in a cluster setting. Therefore, implementations that choose AES-GCM or any AEAD equivalent MUST adopt one of these three alternatives:
チケットの形式はこのドキュメントでは必須ではありませんが、認証された暗号化を使用してチケットを保護することをお勧めします。認証された暗号化に一般的に使用されるアルゴリズムの一部（Galois / Counter Mode（GCM）など）は、ナンスの再利用に対して非常に脆弱であり、この問題はクラスター設定で拡大されます。したがって、AES-GCMまたは同等のAEADを選択する実装では、次の3つの選択肢のいずれかを採用する必要があります。
* Partition the nonce namespace between cluster members and use monotonic counters on each member, e.g., by setting the nonce to the concatenation of the cluster member ID and an incremental counter.
* ナンスをクラスターメンバー間で分割し、ナンスをクラスターメンバーIDと増分カウンターの連結に設定するなどして、各メンバーで単調なカウンターを使用します。
* Generate random nonces but avoid the so-called birthday bound, i.e., never generate more than the maximum allowed number of encrypted tickets (2**64 for AES-128-GCM) for the same ticket pinning protection key.
* ランダムなナンスを生成しますが、いわゆるバースデーバウンドを回避します。つまり、同じチケット固定保護キーに対して、暗号化されたチケットの最大許容数（AES-128-GCMの場合は2 ** 64）より多く生成しないでください。
* An alternative design that has been attributed to Karthik Bhargavan is as follows. Start with a 128-bit master key K_master and then for each encryption, generate a 256-bit random nonce and compute: K = HKDF(K_master, Nonce || "key"), then N = HKDF(K_master, Nonce || "nonce"). Use these values to encrypt the ticket, AES-GCM(K, N, data). This nonce should then be stored and transmitted with the ticket.
* Karthik Bhargavanによると考えられる代替設計は次のとおりです。 128ビットのマスターキーK_masterから開始し、暗号化ごとに256ビットのランダムナンスを生成して計算します。K= HKDF（K_master、Nonce || "key"）、次にN = HKDF（K_master、Nonce || "ノンス」）。これらの値を使用して、チケットAES-GCM（K、N、data）を暗号化します。その後、このナンスは保存され、チケットとともに送信されます。
The IANA has allocated a TicketPinning extension value in the "TLS ExtensionType Values" registry.
IANAは、「TLS ExtensionType値」レジストリでTicketPinning拡張値を割り当てました。
[RFC8447] defines the procedure, requirements, and the necessary information for the IANA to update the "TLS ExtensionType Values" registry [TLS-EXT]. The registration procedure is "Specification Required" [RFC8126].
[RFC8447]は、IANAが「TLS ExtensionType値」レジストリ[TLS-EXT]を更新するための手順、要件、および必要な情報を定義しています。登録手順は「要スペック」【RFC8126】です。
The TicketPinning extension is registered as follows. (The extension is not limited to Private Use, and as such has its first byte in the range 0-254.)
TicketPinning拡張機能は次のように登録されます。 （拡張機能は私的使用に限定されないため、最初のバイトは0〜254の範囲です。）
Value: 32
値：32
Name: ticket_pinning
名前：ticket_pinning
Recommended: No
推奨：いいえ
TLS 1.3: CH, EE (to indicate that the extension is present in ClientHello and EncryptedExtensions messages)
TLS 1.3：CH、EE（拡張がClientHelloおよびEncryptedExtensionsメッセージに存在することを示すため）
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[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>.
[RFC8447] Salowey、J。およびS.ターナー、「TLSおよびDTLSのIANAレジストリ更新」、RFC 8447、DOI 10.17487 / RFC8447、2018年8月、<https://www.rfc-editor.org/info/rfc8447> 。
[Netcraft] Mutton, P., "HTTP Public Key Pinning: You're doing it wrong!", March 2016, <https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html>.
[Netcraft]マトン、P。、「HTTP公開キーのピン留め：間違っている！」、2016年3月、<https://news.netcraft.com/archives/2016/03/30/http-public-key -pinning-youre-doing-it-wrong.html>。
[Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip Handshakes: A Tool for Bidirectional Vouching", Cryptology and Network Security pp. 142-157, 2012.
[オレオ] Berkman、O.、Pinkas、B。、およびM. Yung、「Firm Grip Handshakes：A Tool for Bidirectional Vouching」、暗号化およびネットワークセキュリティ、pp。142-157、2012。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without server-Side State」、RFC 5077、DOI 10.17487 / RFC5077、January 2008、 <https://www.rfc-editor.org/info/rfc5077>。
[RFC5246] 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>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<https://www.rfc-editor.org/info/rfc6454>。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962]ローリーB.、ラングレーA.、およびE.キャスパー、「証明書の透明性」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<https://www.rfc-editor.org/info/rfc6962 >。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https://www.rfc-editor.org/info/rfc7258 >。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<https://www.rfc-editor.org / info / rfc7469>。
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <https://www.rfc-editor.org/info/rfc7507>.
[RFC7507] Moeller、B。およびA. Langley、「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）」、RFC 7507、DOI 10.17487 / RFC7507、2015年4月、<https：//www.rfc-editor .org / info / rfc7507>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D。、およびJ. Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：/ /www.rfc-editor.org/info/rfc8555>。
[TLS-EXT] IANA, "TLS Extension Type Value", <https://www.iana.org/assignments/tls-extensiontype-values/>.
[TLS-EXT] IANA、「TLS拡張タイプ値」、<https://www.iana.org/assignments/tls-extensiontype-values/>。
[TLS-TACK] Marlinspike, M., "Trust Assertions for Certificate Keys", Work in Progress, Internet-Draft, draft-perrin-tls-tack-02, 7 January 2013, <https://tools.ietf.org/html/draft-perrin-tls-tack-02>.
[TLS-TACK] Marlinspike、M。、「証明書キーの信頼アサーション」、作業中、インターネットドラフト、draft-perrin-tls-tack-02、2013年1月7日、<https://tools.ietf.org / html / draft-perrin-tls-tack-02>。
The global PKI system relies on the trust of a CA issuing certificates. As a result, a corrupted trusted CA may issue a certificate for any organization without the organization's approval (a misissued or "fake" certificate), and use the certificate to impersonate the organization. There are many attempts to resolve these weaknesses, including the Certificate Transparency (CT) protocol [RFC6962], HTTP Public Key Pinning (HPKP) [RFC7469], and Trust Assertions for Certificate Keys (TACK) [TLS-TACK].
グローバルPKIシステムは、証明書を発行するCAの信頼に依存しています。その結果、信頼されたCAが破損すると、組織の承認なしに組織の証明書（誤って発行された、または「偽の」証明書）が発行され、その証明書を使用して組織になりすます可能性があります。証明書の透明性（CT）プロトコル[RFC6962]、HTTP公開鍵のピン留め（HPKP）[RFC7469]、証明書の鍵の信頼アサーション（TACK）[TLS-TACK]など、これらの弱点を解決する試みは数多くあります。
CT requires cooperation of a large portion of the hundreds of extant certificate authorities (CAs) before it can be used "for real", in enforcing mode. It is noted that the relevant industry forum (CA/ Browser Forum) is indeed pushing for such extensive adoption. However the public nature of CT often makes it inappropriate for enterprise use because many organizations are not willing to expose their internal infrastructure publicly.
CTは、強制モードで「実際に」使用する前に、何百もの現存する認証局（CA）の大部分の協力を必要とします。関連する業界フォーラム（CA /ブラウザフォーラム）が実際にそのような広範な採用を推進していることに注意してください。ただし、多くの組織は内部のインフラストラクチャを公開することを望んでいないため、CTは公共の性質上、企業での使用に適さないことがよくあります。
TACK has some similarities to the current proposal, but work on it seems to have stalled. Appendix A.2 compares our proposal to TACK.
TACKは現在の提案といくつかの類似点がありますが、その取り組みは行き詰まっているようです。付録A.2では、提案をTACKと比較しています。
HPKP is an IETF standard, but so far has proven hard to deploy. HPKP pins (fixes) a public key, one of the public keys listed in the certificate chain. As a result, HPKP needs to be coordinated with the certificate management process. Certificate management impacts HPKP and thus increases the probability of HPKP failures. This risk is made even higher given the fact that, even though work has been done in the Automated Certificate Management Environment (ACME) working group to automate certificate management, in many or even most cases, certificates are still managed manually. As a result, HPKP cannot be completely automated, resulting in error-prone manual configuration. Such errors could prevent the web server from being accessed by some clients. In addition, HPKP uses an HTTP header, which makes this solution HTTPS specific and not generic to TLS. On the other hand, the current document provides a solution that is independent of the server's certificate management, and that can be entirely and easily automated. Appendix A.1 compares HPKP to the current document in more detail.
HPKPはIETF標準ですが、これまでのところ展開が難しいことが証明されています。 HPKPは、証明書チェーンにリストされている公開鍵の1つである公開鍵をピン留め（修正）します。その結果、HPKPは証明書管理プロセスと調整する必要があります。証明書管理はHPKPに影響を与えるため、HPKPが失敗する可能性が高くなります。自動化された証明書管理環境（ACME）ワーキンググループで証明書管理を自動化するための作業が行われているにもかかわらず、多くの場合またはほとんどの場合でも証明書は依然として手動で管理されているため、このリスクはさらに高くなります。その結果、HPKPは完全に自動化できず、エラーが発生しやすい手動構成になります。このようなエラーにより、一部のクライアントがWebサーバーにアクセスできなくなる可能性があります。さらに、HPKPはHTTPヘッダーを使用するため、このソリューションはHTTPS固有であり、TLSに一般的ではありません。一方、現在のドキュメントは、サーバーの証明書管理から独立したソリューションを提供し、完全かつ簡単に自動化できます。付録A.1では、HPKPと現在のドキュメントを詳細に比較しています。
The ticket pinning proposal augments these mechanisms with a much easier to implement and deploy solution for server identity pinning, by reusing some of the ideas behind TLS session resumption.
チケット固定の提案は、TLSセッション再開の背後にあるアイデアの一部を再利用することにより、サーバーID固定のためのソリューションの実装と展開がはるかに容易になるようにこれらのメカニズムを強化します。
This section compares ticket pinning to two earlier proposals, HPKP and TACK.
このセクションでは、チケットの固定を2つの以前の提案、HPKPとTACKと比較します。
The current IETF standard for pinning the identity of web servers is HPKP [RFC7469].
WebサーバーのIDを固定するための現在のIETF標準はHPKP [RFC7469]です。
The main differences between HPKP and the current document are the following:
HPKPと現在のドキュメントの主な違いは次のとおりです。
* HPKP limits its scope to HTTPS, while the current document considers all application above TLS.
* HPKPはスコープをHTTPSに制限しますが、現在のドキュメントではTLSを超えるすべてのアプリケーションを考慮しています。
* HPKP pins the public key of the server (or another public key along the certificate chain), and as such, is highly dependent on the management of certificates. Such dependency increases the potential error surface, especially as certificate management is not yet largely automated. The current proposal, on the other hand, is independent of certificate management.
* HPKPはサーバーの公開鍵（または証明書チェーンに沿った別の公開鍵）を固定するため、証明書の管理に大きく依存しています。特に証明書の管理がまだほとんど自動化されていないため、このような依存関係により、潜在的なエラーが発生する可能性が高くなります。一方、現在の提案は、証明書管理とは無関係です。
* HPKP pins public keys that are public and used for the standard TLS authentication. Identity pinning relies on the ownership of the pinning key, which is not disclosed to the public and not involved in the standard TLS authentication. As a result, identity pinning is a completely independent, second-factor authentication mechanism.
* HPKPは、公開され、標準のTLS認証に使用される公開鍵をピン留めします。 IDピン留めは、ピン留めキーの所有権に依存します。これは、一般には公開されておらず、標準のTLS認証には含まれていません。その結果、IDピン留めは完全に独立した第2要素認証メカニズムです。
* HPKP relies on a backup key to recover the misissuance of a key. We believe such backup mechanisms add excessive complexity and cost. Reliability of the current mechanism is primarily based on its being highly automated.
* HPKPは、バックアップキーを使用してキーの発行を回復します。そのようなバックアップメカニズムは、過度の複雑さとコストを追加すると考えています。現在のメカニズムの信頼性は、主に高度に自動化されていることに基づいています。
* HPKP relies on the client to report errors to the report-uri. The current document does not need any out-of-band mechanism, and the server is informed automatically. This provides an easier and more reliable health monitoring.
* HPKPはクライアントに依存して、エラーをreport-uriに報告します。現在のドキュメントは帯域外メカニズムを必要とせず、サーバーに自動的に通知されます。これにより、より簡単で信頼性の高いヘルスモニタリングが提供されます。
On the other hand, HPKP shares the following aspects with identity pinning:
一方、HPKPはIDピン留めと次の点を共有しています。
* Both mechanisms provide hard failure. With HPKP, only the client is aware of the failure, while with the current proposal both client and server are informed of the failure. This provides room for further mechanisms to automatically recover from such failures.
* どちらのメカニズムでもハード障害が発生します。 HPKPでは、クライアントのみが障害を認識していますが、現在の提案では、クライアントとサーバーの両方に障害が通知されます。これは、そのような障害から自動的に回復するためのさらなるメカニズムのための余地を提供します。
* Both mechanisms are subject to a server compromise in which users are provided with an invalid ticket (e.g., a random one) or HTTP header with a very long lifetime. For identity pinning, this lifetime SHOULD NOT be longer than 31 days. In both cases, clients will not be able to reconnect the server during this lifetime. With the current proposal, an attacker needs to compromise the TLS layer, while with HPKP, the attacker needs to compromise the HTTP server. Arguably, the TLS-level compromise is typically more difficult for the attacker.
* どちらのメカニズムも、ユーザーに無効なチケット（ランダムなチケットなど）または非常に長いライフタイムのHTTPヘッダーが提供されるサーバーの侵害の影響を受けます。 ID固定の場合、この有効期間は31日を超えてはなりません。どちらの場合も、この存続期間中、クライアントはサーバーに再接続できません。現在の提案では、攻撃者はTLSレイヤーを危険にさらす必要がありますが、HPKPの場合、攻撃者はHTTPサーバーを危険にさらす必要があります。おそらく、TLSレベルの侵害は、通常、攻撃者にとってより困難です。
Unfortunately HPKP has not seen wide deployment yet. As of March 2016, the number of servers using HPKP was less than 3000 [Netcraft]. This may simply be due to inertia, but we believe the main reason is the interactions between HPKP and manual certificate management that is needed to implement HPKP for enterprise servers. The penalty for making mistakes (e.g., being too early or too late to deploy new pins) is that the server becomes unusable for some of the clients.
残念ながら、HPKPはまだ広範囲に展開されていません。 2016年3月の時点で、HPKPを使用するサーバーの数は3000未満でした[Netcraft]。これは単に慣性が原因である可能性がありますが、主な理由は、エンタープライズサーバーにHPKPを実装するために必要なHPKPと手動証明書管理の間の相互作用にあると考えています。間違いを犯すことによるペナルティ（たとえば、新しいピンを配置するには早すぎる、または遅すぎる）は、サーバーが一部のクライアントで使用できなくなることです。
To demonstrate this point, we present a list of the steps involved in deploying HPKP on a security-sensitive web server.
この点を実証するために、セキュリティの影響を受けるWebサーバーにHPKPを展開する際に必要な手順のリストを示します。
1. Generate two public/private key pairs on a computer that is not the live server. The second one is the "backup1" key pair.
1. ライブサーバーではないコンピューターで2つの公開キーと秘密キーのペアを生成します。 2つ目は「backup1」キーペアです。
openssl genrsa -out "example.com.key" 2048;
openssl genrsa -out "example.com.key" 2048;
openssl genrsa -out "example.com.backup1.key" 2048;
openssl genrsa -out "example.com.backup1.key" 2048;
2. Generate hashes for both of the public keys. These will be used in the HPKP header:
2. 両方の公開鍵のハッシュを生成します。これらはHPKPヘッダーで使用されます。
openssl rsa -in "example.com.key" -outform der -pubout | \
openssl dgst -sha256 -binary | openssl enc -base64
openssl rsa -in "example.com.backup1.key" -outform der \
-pubout | openssl dgst -sha256 -binary | openssl enc -base64
3. Generate a single CSR (Certificate Signing Request) for the first key pair, where you include the domain name in the CN (Common Name) field:
3. 最初の鍵ペアに対して単一のCSR（証明書署名要求）を生成します。CN（共通名）フィールドにドメイン名を含めます。
openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Org/ \
CN=example.com" -key "example.com.key" -out "example.com.csr";
4. Send this CSR to the CA and go though the dance to prove you own the domain. The CA will give you a single certificate that will typically expire within a year or two.
4. このCSRをCAに送信し、ダンスを行ってドメインを所有していることを証明します。 CAは、通常1年または2年以内に期限切れになる単一の証明書を提供します。
5. On the live server, upload and set up the first key pair and its certificate. At this point, you can add the "Public-Key-Pins" header, using the two hashes you created in step 2.
5. ライブサーバーで、最初のキーペアとその証明書をアップロードして設定します。この時点で、手順2で作成した2つのハッシュを使用して、「公開キーピン」ヘッダーを追加できます。
Note that only the first key pair has been uploaded to the server so far.
これまでのところ、サーバーにアップロードされているのは最初の鍵ペアのみであることに注意してください。
6. Store the second (backup1) key pair somewhere safe, probably somewhere encrypted like a password manager. It won't expire, as it's just a key pair; it just needs to be ready for when you need to get your next certificate.
6. 2番目の（backup1）鍵ペアを安全な場所に保管します。おそらく、パスワードマネージャーのように暗号化された場所に保管します。それは単なるキーペアであるため、期限切れになりません。次の証明書を取得する必要がある場合に備えておく必要があります。
7. Time passes -- probably just under a year (if waiting for a certificate to expire), or maybe sooner if you find that your server has been compromised, and you need to replace the key pair and certificate.
7. 時間の経過-おそらく1年弱（証明書の有効期限が切れるのを待っている場合）、またはサーバーが危険にさらされていることが判明し、キーペアと証明書を交換する必要がある場合は、もっと早くなる可能性があります。
8. Create a new CSR using the "backup1" key pair, and get a new certificate from your CA.
8. 「backup1」キーペアを使用して新しいCSRを作成し、CAから新しい証明書を取得します。
9. Generate a new backup key pair (backup2), get its hash, and store it in a safe place (again, not on the live server).
9. 新しいバックアップキーペア（backup2）を生成し、そのハッシュを取得して、安全な場所に保存します（ここでも、ライブサーバー上ではありません）。
10. Replace your old certificate and old key pair, update the "Public-Key-Pins" header to remove the old hash, and add the new "backup2" key pair.
10. 古い証明書と古いキーペアを置き換え、「パブリックキーピン」ヘッダーを更新して古いハッシュを削除し、新しい「backup2」キーペアを追加します。
Note that in the above steps, both the certificate issuance as well as the storage of the backup key pair involve manual steps. Even with an automated CA that runs the ACME protocol [RFC8555], key backup would be a challenge to automate.
上記の手順では、証明書の発行とバックアップキーペアの保存の両方に手動の手順が含まれることに注意してください。 ACMEプロトコル[RFC8555]を実行する自動化されたCAを使用する場合でも、キーのバックアップは自動化するのが難しいでしょう。
Compared with HPKP, TACK [TLS-TACK] is more similar to the current document. It can even be argued that this document is a symmetric-cryptography variant of TACK. That said, there are still a few significant differences:
HPKPと比較すると、TACK [TLS-TACK]は現在のドキュメントに似ています。このドキュメントはTACKの対称暗号化バリアントであるとさえ主張することができます。それでも、いくつかの大きな違いがあります。
* Probably the most important difference is that with TACK, validation of the server certificate is no longer required, and in fact TACK specifies it as a "MAY" requirement ([TLS-TACK], Section 5.3). With ticket pinning, certificate validation by the client remains a MUST requirement, and the ticket acts only as a second factor. If the pinning secret is compromised, the server's security is not immediately at risk.
* おそらく最も重要な違いは、TACKではサーバー証明書の検証が不要になり、実際にはTACKがそれを「MAY」要件として指定することです（[TLS-TACK]、セクション5.3）。チケットの固定では、クライアントによる証明書の検証は必須の要件であり、チケットは2番目の要素としてのみ機能します。ピンシークレットが侵害された場合、サーバーのセキュリティはすぐには危険にさらされません。
* Both TACK and the current document are mostly orthogonal to the server certificate as far as their life cycle, and so both can be deployed with no manual steps.
* TACKと現在のドキュメントはどちらも、そのライフサイクルに関する限り、サーバー証明書とほぼ直交しているため、手動の手順なしで両方を展開できます。
* TACK uses Elliptic Curve Digital Signature Algorithm (ECDSA) to sign the server's public key. This allows cooperating clients to share server assertions between themselves. This is an optional TACK feature, and one that cannot be done with pinning tickets.
* TACKは楕円曲線デジタル署名アルゴリズム（ECDSA）を使用してサーバーの公開鍵に署名します。これにより、協調するクライアントは、それらの間でサーバーアサーションを共有できます。これはオプションのTACK機能で、チケットの固定では実行できません。
* TACK allows multiple servers to share its public keys. Such sharing is disallowed by the current document.
* TACKを使用すると、複数のサーバーが公開鍵を共有できます。このような共有は、現在のドキュメントでは許可されていません。
* TACK does not allow the server to track a particular client, and so has better privacy properties than the current document.
* TACKは、サーバーが特定のクライアントを追跡することを許可しないため、現在のドキュメントよりも優れたプライバシープロパティを備えています。
* TACK has an interesting way to determine the pin's lifetime, setting it to the time period since the pin was first observed, with a hard upper bound of 30 days. The current document makes the lifetime explicit, which may be more flexible to deploy. For example, web sites that are only visited rarely by users may opt for a longer period than other sites that expect users to visit on a daily basis.
* TACKには、ピンの有効期間を決定する興味深い方法があり、ピンが最初に観測されてからの期間に設定されます。ハード上限は30日です。現在のドキュメントでは、ライフタイムが明示されており、より柔軟に展開できます。たとえば、ユーザーがめったにアクセスしないWebサイトは、ユーザーが日常的にアクセスすることを期待する他のサイトよりも長い期間を選択する場合があります。
Acknowledgments
謝辞
The original idea behind this proposal was published in [Oreo] by Moti Yung, Benny Pinkas, and Omer Berkman. The current protocol is but a distant relative of the original Oreo protocol, and any errors are the responsibility of the authors of this document alone.
この提案の背後にある元のアイデアは、Moti Yung、Benny Pinkas、Omer Berkmanによって[Oreo]で公開されました。現在のプロトコルは元のOreoプロトコルとはかなり関係があり、エラーはこのドキュメントの作成者のみの責任です。
We would like to thank Adrian Farrel, Dave Garrett, Daniel Kahn Gillmor, Alexey Melnikov, Yoav Nir, Eric Rescorla, Benjamin Kaduk, and Rich Salz for their comments on this document. Special thanks to Craig Francis for contributing the HPKP deployment script, and to Ralph Holz for several fruitful discussions.
このドキュメントに対するコメントを提供してくれたAdrian Farrel、Dave Garrett、Daniel Kahn Gillmor、Alexey Melnikov、Yoav Nir、Eric Rescorla、Benjamin Kaduk、Rich Salzに感謝します。 HPKP導入スクリプトを提供してくれたCraig Francisと、いくつかの有益な議論をしてくれたRalph Holzに特に感謝します。
Authors' Addresses
著者のアドレス
Yaron Sheffer Intuit
Yaron Sheffer Intuit
Email: yaronf.ietf@gmail.com
Daniel Migault Ericsson
ダニエル・ミゴー・エリクソン
Email: daniel.migault@ericsson.com