TLS Working Group E. Rescorla
Internet-Draft Windy Hill Systems, LLC
Intended status: Standards Track R. Barnes
Expires: 25 April 2024 Cisco
H. Tschofenig
B. Schwartz
Google
23 October 2023
Compact TLS 1.3 draft-ietf-tls-ctls-09
コンパクトTLS 1.3ドラフト-ITEF-TLS-CTLS-09
Abstract
概要
This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS.
このドキュメントは、TLS 1.3およびDTLS 1.3の「コンパクト」バージョンを指定します。時代遅れの素材、タイトなエンコード、テンプレートベースの専門化技術、および代替暗号化技術をトリミングすることにより、帯域幅を節約します。CTLSは、ワイヤのフレーミングが異なるため、TLS 1.3またはDTLS 1.3と直接相互運用できません。ただし、単一のサーバーは、TLSまたはDTLと一緒にCTLを提供できます。
Status of This Memo
本文書の位置付け
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に適合して提出されています。
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループは、作業文書をインターネットドラフトとして配布する場合もあることに注意してください。現在のインターネットドラフトのリストは、https：//datatracker.ietf.org/drafts/current/にあります。
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
インターネットドラフトは、最大6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントに更新、交換、または廃止される場合があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」以外に引用することは不適切です。
This Internet-Draft will expire on 25 April 2024.
このインターネットドラフトは、2024年4月25日に期限切れになります。
Copyright Notice
著作権表示
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。
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.
この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2.1. Template-based Specialization . . . . . . . . . . . . . . 3
2.1.1. Initial template elements . . . . . . . . . . . . . . 6
2.1.2. Static vector compression . . . . . . . . . . . . . . 12
2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 13
2.3. cTLS Handshake Layer . . . . . . . . . . . . . . . . . . 15
2.3.1. The Transport layer . . . . . . . . . . . . . . . . . 15
2.3.2. The Transcript layer . . . . . . . . . . . . . . . . 16
2.3.3. The Logical layer . . . . . . . . . . . . . . . . . . 17
3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 17
3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 18
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Adding a ContentType . . . . . . . . . . . . . . . . . . 19
6.2. Template Keys . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Adding a cTLS Template message type . . . . . . . . . . . 20
6.4. Activating the HelloRetryRequest MessageType . . . . . . 21
6.5. Reserved profiles . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
This document specifies "compact" versions of TLS [RFC8446] and DTLS [RFC9147], respectively known as "Stream cTLS" and "Datagram cTLS". cTLS provides equivalent security and functionality to TLS and DTLS, but it is designed to take up minimal bandwidth. The space reduction is achieved by five basic techniques:
このドキュメントは、それぞれ「Stream CTLS」および「Datagram CTLS」として知られているTLS [RFC8446]およびDTLS [RFC9147]の「コンパクト」バージョンを指定します。CTLSは、TLSとDTLSに同等のセキュリティと機能を提供しますが、最小限の帯域幅を占有するように設計されています。空間削減は、5つの基本的な手法によって達成されます。
* Omitting unnecessary values that are a holdover from previous versions of TLS.
* TLSの以前のバージョンからのホールドオーバーである不必要な値を省略します。
* Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions.
* 以前のTLSバージョンで後方互換性を維持するために必要なフィールドと握手メッセージを省略します。
* More compact encodings.
* よりコンパクトなエンコーディング。
* A template-based specialization mechanism that allows pre-populating information at both endpoints without the need for negotiation.
* 交渉を必要とせずに、両方のエンドポイントで情報を事前に入力できるようにするテンプレートベースの専門化メカニズム。
* Alternative cryptographic techniques, such as nonce truncation.
* ノンセの切り捨てなどの代替暗号化技術。
For the common (EC)DHE handshake with pre-established certificates, Stream cTLS achieves an overhead of 53 bytes over the minimum required by the cryptovariables. For a PSK handshake, the overhead is 21 bytes. An annotated handshake transcript can be found in Appendix A.
事前に確立された証明書を使用した一般的な（EC）DHEの握手の場合、Stream CTLSは、Cryptovariablesが必要とする最小値にわたって53バイトのオーバーヘッドを達成します。PSKの握手の場合、オーバーヘッドは21バイトです。注釈付きの握手の成績証明書は、付録Aにあります。
TODO: Make a PSK transcript and check the overhead.
TODO：PSK転写産物を作成し、オーバーヘッドを確認します。
cTLS supports the functionality of TLS and DTLS 1.3, and is forward-compatible to future versions of TLS and DTLS. cTLS itself is versioned by CTLSTemplate.version (currently zero).
CTLSは、TLSおよびDTLS 1.3の機能をサポートしており、TLSおよびDTLSの将来のバージョンとは順応性があります。CTLS自体は、CTLSTEMPLATE.VERSION（現在はゼロ）によってバージョンされています。
The compression of the handshake while preserving the security guarantees of TLS has been formally verified in [Comparse].
TLSのセキュリティ保証を維持する際の握手の圧縮は、[比較]で正式に検証されています。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Structure definitions listed below override TLS 1.3 definitions; any PDU not internally defined is taken from TLS 1.3.
以下にリストされている構造定義TLS 1.3定義をオーバーライドします。内部的に定義されていないPDUは、TLS 1.3から取得されます。
A significant transmission overhead in TLS 1.3 is contributed to by two factors:
TLS 1.3の重要なトランスミッションオーバーヘッドは、2つの要因によって寄与されます。
* the negotiation of algorithm parameters, and extensions, as well as
* アルゴリズムパラメーター、および拡張機能の交渉、および
* the exchange of certificates.
* 証明書の交換。
TLS 1.3 supports different credential types and modes that are impacted differently by a compression scheme. For example, TLS supports certificate-based authentication, raw public key-based authentication as well as pre-shared key (PSK)-based authentication. PSK-based authentication can be used with externally configured PSKs or with PSKs established through tickets.
TLS 1.3は、圧縮スキームによって異なる影響を与えるさまざまな資格情報タイプとモードをサポートします。たとえば、TLSは、証明書ベースの認証、生の公開キーベースの認証、および事前共有キー（PSK）ベースの認証をサポートしています。PSKベースの認証は、外部で構成されたPSKまたはチケットを介して確立されたPSKで使用できます。
The basic idea of template-based specialization is that we start with the basic TLS 1.3 handshake, which is fully general and then remove degrees of freedom, eliding parts of the handshake which are used to express those degrees of freedom. For example, if we only support one version of TLS, then it is not necessary to have version negotiation and the supported_versions extension can be omitted. Thus, each specialization produces a new protocol that preserves the security guarantees of TLS, but has its own unique handshake.
テンプレートベースの専門化の基本的なアイデアは、基本的なTLS 1.3の握手から始めて、完全に一般的であり、自由度を除去し、それらの自由度を表現するために使用される握手の一部を排除することです。たとえば、TLSの1つのバージョンのみをサポートする場合、バージョンのネゴシエーションを行う必要はなく、supported_versions拡張子を省略できます。したがって、各専門化は、TLSのセキュリティ保証を保持する新しいプロトコルを生成しますが、独自の握手があります。
By assuming that out-of-band agreements took place already prior to the start of the cTLS protocol exchange, the amount of data exchanged can be radically reduced. Because different clients may use different compression templates and because multiple compression templates may be available for use in different deployment environments, a client needs to inform the server about the profile it is planning to use. The profile field in the ClientHello serves this purpose.
CTLSプロトコル交換の開始前にすでに帯域外契約が発生していると仮定することにより、交換されるデータの量を根本的に削減できます。異なるクライアントは異なる圧縮テンプレートを使用する場合があり、異なる展開環境で使用できるように複数の圧縮テンプレートが使用できるため、クライアントは使用する予定のプロファイルについてサーバーに通知する必要があります。ClientHelloのプロファイルフィールドは、この目的に役立ちます。
Although the template-based specialization mechanisms described here are general, we also include specific mechanism for certificate-based exchanges because those are where the most complexity and size reduction can be obtained. Most of the other exchanges in TLS 1.3 are highly optimized and do not require compression to be used.
ここで説明するテンプレートベースの専門化メカニズムは一般的ですが、最も複雑さとサイズの削減を得ることができるため、証明書ベースの交換用の特定のメカニズムも含まれています。TLS 1.3の他の交換のほとんどは高度に最適化されており、圧縮を使用する必要はありません。
The compression profile defining the use of algorithms, algorithm
parameters, and extensions is represented by the CTLSTemplate
structure:
enum {
profile(0),
version(1),
cipher_suite(2),
dh_group(3),
signature_algorithm(4),
random(5),
mutual_auth(6),
handshake_framing(7),
client_hello_extensions(8),
server_hello_extensions(9),
encrypted_extensions(10),
certificate_request_extensions(11),
known_certificates(12),
finished_size(13),
optional(65535)
} CTLSTemplateElementType;
struct {
CTLSTemplateElementType type;
opaque data<0..2^32-1>;
} CTLSTemplateElement;
struct {
uint16 ctls_version = 0;
CTLSTemplateElement elements<0..2^32-1>
} CTLSTemplate;
Elements in a CTLSTemplate MUST appear sorted by the type field in strictly ascending order. The initial elements are defined in the subsections below. Future elements can be added via an IANA registry (Section 6.2). When generating a template, all elements are OPTIONAL to include. When processing a template, all elements are mandatory to understand (but see discussion of optional in Section 2.1.1.11).
CTLSTEMプレート内の要素は、タイプフィールドによって厳密に昇順でソートされているように見える必要があります。初期要素は、以下のサブセクションで定義されています。将来の要素は、IANAレジストリ（セクション6.2）を介して追加できます。テンプレートを生成するとき、すべての要素はオプションを含めることができます。テンプレートを処理する場合、すべての要素が理解できるように必須です（ただし、セクション2.1.1.11でオプションの説明を参照）。
For ease of configuration, an equivalent JSON dictionary format is also defined. It consists of a dictionary whose keys are the name of each element type (converted from snake_case to camelCase), and whose values are a type-specific representation of the element intended to maximize legibility. The cTLS version is represented by the key "ctlsVersion", whose value is an integer, defaulting to 0 if omitted.
構成を容易にするために、同等のJSON辞書形式も定義されています。キーが各要素タイプの名前である辞書で構成されています（snake_caseからcamelcaseに変換）、値は読みやすさを最大化することを目的とした要素のタイプ固有の表現です。CTLSバージョンは、整数であるキー「CTLSversion」で表されます。
For example, the following specialization describes a protocol with a single fixed version (TLS 1.3) and a single fixed cipher suite (TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites, ServerHello.cipher_suites, and the supported_versions extensions in the ClientHello and ServerHello would be omitted.
たとえば、次の専門分野では、単一の固定バージョン（TLS 1.3）と単一の固定暗号スイート（TLS_AES_128_GCM_SHA256）を備えたプロトコルについて説明しています。ワイヤーでは、clienthello.ciphel_suites、serverhello.cipher_suites、およびclienthelloおよびserverhelloのsupported_versions拡張機能が省略されます。
{
"ctlsVersion": 0,
"profile": "0001020304050607",
"version": 772,
"cipherSuite": "TLS_AES_128_GCM_SHA256"
}
This element identifies the profile being defined. Its binary value is:
この要素は、定義されているプロファイルを識別します。そのバイナリ値は次のとおりです。
opaque ProfileID<1..2^8-1>
This encodes the profile ID, if one is specified. IDs whose decoded length is 4 bytes or less are reserved (see Section 6.5). When a reserved value is used (including the default value), other keys MUST NOT appear in the template, and a client MUST NOT accept the template unless it recognizes the ID.
これは、指定されている場合、プロファイルIDをエンコードします。デコードされた長さが4バイト以下のIDは予約されています（セクション6.5を参照）。予約済みの値が使用されている場合（デフォルト値を含む）、他のキーがテンプレートに表示されてはならず、クライアントはIDを認識しない限りテンプレートを受け入れてはなりません。
In JSON, the profile ID is represented as a hexadecimal-encoded string.
JSONでは、プロファイルIDは16進数エンコード文字列として表されます。
Value: a single ProtocolVersion ([RFC8446], Section 4.1.2) that both parties agree to use. For TLS 1.3, the ProtocolVersion is 0x0304.
値：両方の当事者が使用することに同意する単一のプロトコルバージョン（[RFC8446]、セクション4.1.2）。TLS 1.3の場合、プロトコルバージョンは0x0304です。
When this element is included, the supported_versions extension is omitted from ClientHello.extensions.
この要素が含まれている場合、supported_versions拡張子はclienthello.extensionsから省略されます。
In JSON, the version is represented as an integer (772 = 0x0304 for TLS 1.3).
JSONでは、バージョンは整数として表されます（TLS 1.3の場合は772 = 0x0304）。
Value: a single CipherSuite ([RFC8446], Section 4.1.2) that both parties agree to use.
値：両当事者が使用することに同意する単一のciphersuite（[rfc8446]、セクション4.1.2）。
When this element is included, the ClientHello.cipher_suites and ServerHello.cipher_suite fields are omitted.
この要素が含まれている場合、clienthello.cipher_suitesとserverhello.ciphel_suiteフィールドは省略されています。
In JSON, the cipher suite is represented using the "TLS_AEAD_HASH" syntax defined in [RFC8446], Section 8.4.
JSONでは、[RFC8446]、セクション8.4で定義されている「TLS_AEAD_HASH」構文を使用して、暗号スイートが表されます。
Value: a single CTLSKeyShareGroup to use for key establishment.
値：重要な設立に使用する単一のCTLSKEYSHAREGROUP。
struct {
NamedGroup group_name;
uint16 key_share_length;
} CTLSKeyShareGroup;
This is equivalent to adding a "supported_groups" extension to every message where that is allowed (i.e. ClientHello and EncryptedExtensions, in TLS 1.3) consisting solely of the group CTLSKeyShareGroup.group_name.
これは、グループctlskeysharegroup.group_nameグループのみで構成される、許可されているすべてのメッセージ（つまり、TLS 1.3のClienthelloおよび暗号化されたテクステンション）に「supported_groups」拡張機能を追加することと同等です。
Static vectors (see Section 2.1.2):
静的ベクトル（セクション2.1.2を参照）：
* KeyShareClientHello.client_shares
* keyshareclienthello.client_shares
* KeyShareEntry.key_exchange, if CTLSKeyShareGroup.key_share_length is non-zero.
* keyshareentry.key_exchange、ctlskeysharegroup.key_share_lengthがゼロではない場合。
In JSON, this value is represented as a dictionary with two keys: * groupName: a string containing the code point name from the TLS Supported Groups registry (e.g., "x25519"). * keyShareLength: an integer, defaulting to zero if omitted.
JSONでは、この値は2つのキーを持つ辞書として表されます。 * GroupName：TLSサポートグループレジストリのコードポイント名を含む文字列（例： "x25519"）。* keysharelength：整数、省略した場合はゼロになります。
Value: a single CTLSSignatureAlgorithm to use for authentication.
値：認証に使用する単一のCTLS SIGNATUREALGORITHM。
struct {
SignatureScheme signature_scheme;
uint16 signature_length;
} CTLSSignatureAlgorithm;
This is equivalent to a placing a literal "signature_algorithms" extension consisting solely of CTLSSignatureAlgorithm.signature_scheme in every extensions field where the "signature_algorithms" extension is permitted to appear (i.e. ClientHello and CertificateRequest, in TLS 1.3). When this element is included, CertificateVerify.algorithm is omitted.
これは、ctlssignaturealgorithm.signature_schemeのみで構成される文字通りの「signature_algorithms」拡張機能を配置することと同等です。「signature_algorithms」拡張機能が表示されるすべての拡張フィールド（すなわち、クライアントヘロと証明書1.3）が表示されます。この要素が含まれている場合、cermostverify.algorithmは省略されています。
Static vectors (see Section 2.1.2):
静的ベクトル（セクション2.1.2を参照）：
* CertificateVerify.signature, if CTLSSignatureAlgorithm.signature_length is non-zero.
* certificationverify.signature、ctlssignaturealgorithm.signature_lengthはゼロではありません。
In JSON, the signature algorithm is listed by the code point name in [RFC8446], Section 4.2.3. (e.g., ecdsa_secp256r1_sha256). In JSON, this value is represented as a dictionary with two keys: * signatureScheme: a string containing the code point name in the TLS SignatureScheme registry (e.g., "ecdsa_secp256r1_sha256"). * signatureLength: an integer, defaulting to zero if omitted.
JSONでは、署名アルゴリズムは[RFC8446]、セクション4.2.3のコードポイント名によってリストされています。（例：ECDSA_SECP256R1_SHA256）。JSONでは、この値は2つのキーを持つ辞書として表されます。 * SignatureScheme：TLS SignatureSchemeレジストリにコードポイント名を含む文字列（ "ECDSA_SECP256R1_SHA256"）。* SignatureLength：整理された整数。省略した場合はゼロになります。
Value: a single uint8.
値：単一のUINT8。
The ClientHello.Random and ServerHello.Random values are truncated to the given length. Where a 32-byte Random is required, the Random is padded to the right with 0s and the anti-downgrade mechanism in [RFC8446], Section 4.1.3 is disabled. IMPORTANT: Using short Random values can lead to potential attacks. The Random length MUST be less than or equal to 32 bytes.
clienthello.randomおよびserverhello.randomの値は、与えられた長さに切り捨てられます。32バイトのランダムが必要な場合、ランダムは0Sと[RFC8446]のアンチダウングラードメカニズムで右にパッドで埋められ、セクション4.1.3は無効になります。重要：短いランダム値を使用すると、潜在的な攻撃につながる可能性があります。ランダムな長さは、32バイト以下でなければなりません。
OPEN ISSUE: Karthik Bhargavan suggested the idea of hashing ephemeral public keys and to use the result (truncated to 32 bytes) as random values. Such a change would require a security analysis.
未解決の問題：Karthik Bhargavanは、短命の公開キーをハッシュし、結果（32バイトに切り捨てられた）をランダムな値として使用するという考えを提案しました。このような変更には、セキュリティ分析が必要になります。
In JSON, the length is represented as an integer.
JSONでは、長さは整数として表されます。
Value: a single uint8, with 1 representing "true" and 0 representing "false". All other values are forbidden.
値：単一のUINT8、1は「true」を表し、0は「false」を表します。他のすべての値は禁止されています。
If set to true, this element indicates that the client must authenticate with a certificate by sending Certificate and a CertificateVerify message. If the CertificateRequest message does not add information not already conveyed in the template, the server SHOULD omit it.
Trueに設定されている場合、この要素は、クライアントが証明書とCertifativeVerifyメッセージを送信して証明書で認証する必要があることを示します。cirtermateRequestメッセージがテンプレートにまだ伝えられていない情報を追加しない場合、サーバーはそれを省略する必要があります。
In JSON, this value is represented as true or false.
JSONでは、この値は真または偽として表されます。
TODO: It seems like there was an intent to elide the Certificate.certificate_request_context field, but this is not stated explicitly anywhere.
TODO：証明書を削除する意図があったようです。certificate_request_contextフィールドは、明示的には明示的ではありません。
Value: uint8, with 0 indicating "false" and 1 indicating "true". If true, handshake messages MUST be conveyed inside a Handshake ([RFC8446], Section 4) struct on reliable, ordered transports, or a DTLSHandshake ([RFC9147], Section 5.2) struct otherwise, and MAY be broken into multiple records as in TLS and DTLS. If false, each handshake message is conveyed in a CTLSHandshake or CTLSDatagramHandshake struct (Section 2.3), which MUST be the payload of a single record.
値：uint8、0は「false」を示し、1は「真」を示します。真実の場合、握手メッセージは、信頼できる順序輸送、またはDTLSHANDSHAKE（[RFC9147]、セクション5.2）構造の握手（[RFC8446]、セクション4）の構造内で伝えなければなりません。およびdtls。falseの場合、各ハンドシェイクメッセージは、CTLShandshakeまたはCTLSDatagramHandshake struct（セクション2.3）で伝えられます。これは、単一のレコードのペイロードでなければなりません。
In JSON, this value is represented as true or false.
JSONでは、この値は真または偽として表されます。
Value: a single CTLSExtensionTemplate struct:
値：単一のctlsextensionTemplate struct：
struct {
Extension predefined_extensions<0..2^16-1>;
ExtensionType expected_extensions<0..2^16-1>;
ExtensionType self_delimiting_extensions<0..2^16-1>;
uint8 allow_additional;
} CTLSExtensionTemplate;
The predefined_extensions field indicates extensions that should be treated as if they were included in the corresponding message. This allows these extensions to be omitted entirely.
predefined_extensionsフィールドは、対応するメッセージに含まれているかのように扱う必要がある拡張機能を示します。これにより、これらの拡張機能を完全に省略できます。
The expected_extensions field indicates extensions that must be included in the corresponding message, at the beginning of its extensions field. The types of these extensions are omitted when serializing the extensions field of the corresponding message.
expected_extensionsフィールドは、拡張機能フィールドの先頭にある対応するメッセージに含める必要がある拡張機能を示します。これらの拡張機能のタイプは、対応するメッセージの拡張機能フィールドをシリアル化するときに省略されます。
The self_delimiting_extensions field indicates extensions whose data is self-delimiting. The cTLS implementation MUST be able to parse all these extensions, and all extensions listed in Section 4.2 of [RFC8446].
self_delimiting_extensionsのフィールドは、データが自己決定的な拡張機能を示します。CTLS実装は、これらすべての拡張機能と、[RFC8446]のセクション4.2にリストされているすべての拡張機能を解析できる必要があります。
The allow_additional field MUST be 0 (false) or 1 (true), indicating whether additional extensions are allowed here.
Alow_Additionalフィールドは0（false）または1（true）でなければならず、ここで追加の拡張機能が許可されているかどうかを示します。
predefined_extensions and expected_extensions MUST be in strictly ascending order by ExtensionType, and a single ExtensionType MUST NOT appear in both lists. If the version, dh_group, or signature_algorithm element appears in the template, the corresponding ExtensionType MUST NOT appear here. The pre_shared_key ExtensionType MUST NOT appear in either list.
predefined_extensionsとexpected_extensionsは、extensionTypeによって厳密に昇順である必要があり、単一の拡張子型が両方のリストに表示されない必要があります。バージョン、dh_group、またはsignature_algorithm要素がテンプレートに表示されている場合、対応するextensionTypeがここに表示されない必要があります。pre_shared_key extensionTypeはどちらのリストにも表示されない必要があります。
OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.
未解決の問題：hex値とは対照的に、特別な治療の恩恵を受ける他の拡張機能があります。
Static vectors (see Section 2.1.2):
静的ベクトル（セクション2.1.2を参照）：
* Extension.extension_data for any extension whose type is in self_delimiting_extensions, or is listed in Section 4.2 of [RFC8446] except padding. This applies only to the corresponding message.
* extension.extension_dataタイプがself_delimiting_extensionsにある、またはパディングを除く[rfc8446]のセクション4.2にリストされている任意の拡張機能の場合。これは、対応するメッセージにのみ適用されます。
* The extensions field of the corresponding message, if allow_additional is false.
* Allow_Additionalがfalseの場合、対応するメッセージの拡張フィールド。
In JSON, this value is represented as a dictionary with three keys:
JSONでは、この値は3つのキーを持つ辞書として表されます。
* predefinedExtensions: a dictionary mapping ExtensionType names ([RFC8446], Section 4.2) to values encoded as hexadecimal strings.
* predefinedextensions：六十種類の文字列としてエンコードされた値への辞書マッピングextensionType名（[RFC8446]、セクション4.2）。
* expectedExtensions: an array of ExtensionType names.
* expectsextensions：extensionType名の配列。
* selfDelimitingExtensions: an array of ExtensionType names.
* selfdelimitingextensions：extensionType名の配列。
* allowAdditional: true or false.
* AlowAdditional：trueまたはfalse。
If predefinedExtensions or expectedExtensions is empty, it MAY be omitted.
predefinedextensionsまたはexpectsextensionsが空の場合、省略される場合があります。
OPEN ISSUE: Should we have a certificate_entry_extensions element?
OPENの問題：certificate_entry_extensions要素がある必要がありますか？
Value: uint8, indicating that the Finished value is to be truncated to the given length.
値：UINT8。完成した値が与えられた長さに切り捨てられることを示しています。
OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the native hash and TLS 1.2 used 12 bytes. More analysis is needed to know the minimum safe Finished size. See [RFC8446], Appendix E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA. The minimum safe size may vary depending on whether the template was learned via a trusted channel.
未解決の問題：これをどれほど短くする必要がありますか？TLS 1.3は、ネイティブハッシュおよびTLS 1.2を使用して12バイトを使用します。最小安全な完成サイズを知るには、さらに分析が必要です。詳細については、[RFC8446]、付録E.1を参照してください。最小安全サイズは、信頼できるチャネルを介してテンプレートが学習されたかどうかによって異なる場合があります。
In JSON, this length is represented as an integer.
JSONでは、この長さは整数として表されます。
Value: a CTLSTemplate containing elements that are not required to be understood by the client. Server operators MUST NOT place an element in this section unless the server is able to determine whether the client is using it from the client data it receives. A key MUST NOT appear in both the main template and the optional section.
値：クライアントが理解する必要がない要素を含むCTLSTEMプレート。サーバーオペレーターは、クライアントが受信したクライアントデータからクライアントがそれを使用しているかどうかを決定できない限り、このセクションに要素を配置してはなりません。キーは、メインテンプレートとオプションのセクションの両方に表示されてはなりません。
In JSON, this value is represented in the same way as the CTLSTemplate itself.
JSONでは、この値はCTLSTEMプレート自体と同じように表されます。
Value: a CertificateMap struct:
値：certificatemap struct：
struct {
opaque id<1..2^8-1>;
opaque cert_data<1..2^16-1>;
} CertificateMapEntry;
struct {
CertificateMapEntry entries<2..2^24-1>;
} CertificateMap;
Entries in the certificate map must appear in strictly ascending lexicographic order by ID.
証明書マップのエントリは、IDによって厳密に昇順の辞書順に表示される必要があります。
In JSON, CertificateMap is represented as a dictionary from id to cert_data, which are both represented as hexademical strings:
JSONでは、CertiberateMapはIDからCERT_DATAへの辞書として表されます。どちらも六十章の文字列として表されます。
{
"00": "3082...",
"01": "3082...",
}
Certificates are a major contributor to the size of a TLS handshake. In order to avoid this overhead when the parties to a handshake have already exchanged certificates, a compression profile can specify a dictionary of "known certificates" that effectively acts as a compression dictionary on certificates.
証明書は、TLSの握手の規模の主要な貢献者です。握手の当事者がすでに証明書を交換しているこのオーバーヘッドを回避するために、圧縮プロファイルは、証明書の圧縮辞書として効果的に機能する「既知の証明書」の辞書を指定できます。
When compressing a Certificate message, the sender examines the cert_data field of each CertificateEntry. If the cert_data matches a value in the known certificates object, then the sender replaces the cert_data with the corresponding key. Decompression works the opposite way, replacing keys with values.
証明書メッセージを圧縮するとき、送信者は各CertilementEntryのCERT_DATAフィールドを調べます。CERT_DATAが既知の証明書オブジェクトの値と一致する場合、送信者はCERT_DATAを対応するキーに置き換えます。減圧は反対の方法で機能し、キーを値に置き換えます。
Note that in this scheme, there is no signaling on the wire for whether a given cert_data value is compressed or uncompressed. Known certificates objects SHOULD be constructed in such a way as to avoid a uncompressed object being mistaken for compressed one and erroneously decompressed. For X.509, it is sufficient for the first byte of the compressed value (key) to have a value other than 0x30, since every X.509 certificate starts with this byte.
このスキームでは、特定のCERT_DATA値が圧縮または非圧縮されているかどうかについて、ワイヤに信号がないことに注意してください。既知の証明書オブジェクトは、圧縮されていないオブジェクトが圧縮されたものと間違われ、誤って減圧されないように構築する必要があります。X.509の場合、すべてのX.509証明書がこのバイトから始まるため、圧縮値の最初のバイト（キー）が0x30以外の値を持つことは十分です。
This element can be used to compress both client and server certificates. However, in most deployments where client certificates are used, it would be inefficient to encode all client certificates into a single profile. Instead, deployments can define a unique profile for each client, distinguished by the profile ID. Note that the profile ID is sent in cleartext, so this strategy has significant privacy implications.
この要素は、クライアント証明書とサーバー証明書の両方を圧縮するために使用できます。ただし、クライアント証明書が使用されるほとんどの展開では、すべてのクライアント証明書を単一のプロファイルにエンコードすることは非効率的です。代わりに、展開は、プロファイルIDによって区別される各クライアントの一意のプロファイルを定義できます。プロファイルIDはClearTextで送信されるため、この戦略にはプライバシーの重要な意味があります。
Some cTLS template elements imply that certain vectors (as defined in [RFC8446], Section 3.4) have a fixed number of elements during the handshake. These template elements note these "static vectors" in their definition. When encoding a "static vector", its length prefix is omitted.
一部のCTLSテンプレート要素は、特定のベクトル（[RFC8446]、セクション3.4で定義されている）が握手中に固定数の要素を持っていることを意味します。これらのテンプレート要素は、これらの「静的ベクトル」を定義に注目しています。「静的ベクトル」をエンコードするとき、その長さのプレフィックスは省略されています。
For example, suppose that the cTLS template is:
たとえば、CTLSテンプレートは次のとおりです。
{
"ctlsVersion": 0,
"version": 772,
"dhGroup": {
"groupName": "x25519",
"keyShareLength": 32
},
"clientHelloExtensions": {
"expectedExtensions": ["key_share"],
"allowAdditional": false
}
}
Then, the following structure:
次に、次の構造：
28 // length(extensions)
33 26 // extension_type = KeyShare
0024 // length(client_shares)
001d // KeyShareEntry.group
0020 // length(KeyShareEntry.key_exchange)
a690...af948 // KeyShareEntry.key_exchange
is compressed down to:
圧縮されています：
a690...af948 // KeyShareEntry.key_exchange
a690 ... af948 // keyshareentry.key_exchange
according to the following rationale:
次の根拠によると、
* The length of extensions is omitted because allowAdditional is false, so the number of items in extensions (i.e., 1) is known in advance.
* AllowAdditionalが偽であるため、拡張機能の長さは省略されているため、拡張機能（つまり、1）のアイテムの数は事前に知られています。
* extension_type is omitted because it is specified by expected_extensions.
* extension_typeは、expection_extensionsで指定されているため省略されています。
* The length of client_shares is omitted because the use of dhGroup implies that there can only be one KeyShareEntry.
* dhgroupの使用は、キーシェアエントリーが1つしかないことを意味するため、client_sharesの長さが省略されています。
* KeyShareEntry.group is omitted because it is specified by dhGroup.
* keyShareentry.groupは、DHGroupで指定されているため省略されています。
* The length of the key_exchange is omitted because the "x25519" key share has a fixed size (32 bytes).
* 「x25519」キー共有の固定サイズ（32バイト）があるため、key_exchangeの長さは省略されています。
The only cTLS records that are sent in plaintext are handshake records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are the same as TLS/DTLS alerts and use the same content types. For handshake records, we set the content_type field to a fixed cTLS-specific value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple.
プレーンテキストで送信される唯一のCTLSレコードは、ハンドシェイクレコード（clienthelloおよびserverhello/hrr）とアラートです。CTLSアラートは、TLS/DTLSアラートと同じであり、同じコンテンツタイプを使用します。ハンドシェイクレコードの場合、CONTERT_TYPEフィールドを固定CTLS固有の値に設定して、CTLSプレーンテキストレコードを暗号化されたレコード、TLS/DTLSレコード、および同じ5タプルを使用して他のプロトコルと区別します。
struct {
ContentType content_type = ctls_handshake;
opaque profile_id<0..2^8-1>;
opaque fragment<0..2^16-1>;
} CTLSClientPlaintext;
The profile_id field MUST identify the profile that is in use. A zero-length ID corresponds to the cTLS default protocol. The server's reply does not include the profile_id, because the server must be using the same profile indicated by the client.
Profile_idフィールドは、使用されているプロファイルを識別する必要があります。ゼロ長IDは、CTLSデフォルトプロトコルに対応します。サーバーは、クライアントが指定した同じプロファイルを使用している必要があるため、サーバーの返信にはProfile_IDが含まれていません。
struct {
ContentType content_type = ctls_handshake;
opaque fragment<0..2^16-1>;
} CTLSServerPlaintext;
Encrypted records use DTLS 1.3 [RFC9147] record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields. The encryption process and additional data are also as described in DTLS.
暗号化されたレコードは、DTLS 1.3 [RFC9147]レコードフレーミングを使用します。暗号化プロセスと追加データもDTLSで説明されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID | Legend:
| (if any, |
/ length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch
|Sequence Number|
| (if present) |
+-+-+-+-+-+-+-+-+
| 16 bit Length |
| (if present) |
+-+-+-+-+-+-+-+-+
struct {
opaque unified_hdr[variable];
opaque encrypted_record[length];
} CTLSCiphertext;
The presence and size of the connection ID field is negotiated as in DTLS.
接続IDフィールドの存在とサイズは、DTLSのようにネゴシエートされます。
As with DTLS, the length field MAY be omitted by clearing the L bit, which means that the record consumes the entire rest of the data in the lower level transport. In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram. In stream-oriented transports (e.g., TCP), the length field MUST be present. For use over other transports length information may be inferred from the underlying layer.
DTLSと同様に、Lビットをクリアすることで長さフィールドを省略できます。つまり、レコードは低レベルの輸送で残りのデータ全体を消費します。この場合、同じデータグラムに長さフィールドのない複数のDTLSciphertext形式のレコードを使用することはできません。ストリーム指向のトランスポンド（TCPなど）では、長さフィールドが存在する必要があります。他の輸送で使用するには、基礎となる層から長さの情報が推測される場合があります。
Normal DTLS does not provide a mechanism for suppressing the sequence number field entirely. When a reliable, ordered transport (e.g., TCP) is in use, the S bit in the configuration octet MUST be cleared and the sequence number MUST be omitted. When an unreliable transport is in use, the S bit has its usual meaning and the sequence number MUST be included.
通常のDTLSは、シーケンス番号フィールドを完全に抑制するメカニズムを提供しません。信頼できる順序付けられた輸送（TCPなど）が使用されている場合、構成のSビットをクリアし、シーケンス番号を省略する必要があります。信頼できないトランスポートが使用されている場合、Sビットには通常の意味があり、シーケンス番号を含める必要があります。
The cTLS handshake is modeled in three layers:
CTLSハンドシェイクは、3つの層でモデル化されています。
1. The Transport layer
1. 輸送層
2. The Transcript layer
2. 転写層
3. The Logical layer
3. 論理レイヤー
When template.handshake_framing is false, the cTLS transport layer uses a custom handshake framing that saves space by relying on the record layer for message lengths. (This saves 3 bytes per message compared to TLS, or 9 bytes compared to DTLS.) This compact framing is defined by the CTLSHandshake and CTLSDatagramHandshake structs.
Template.Handshake_Framingがfalseの場合、CTLSトランスポートレイヤーは、メッセージの長さをレコードレイヤーに依存することでスペースを節約するカスタムハンドシェイクフレーミングを使用します。（これにより、TLSと比較してメッセージごとに3バイト、またはDTLSと比較して9バイトを節約します。）このコンパクトなフレーミングは、CTLShandShakeおよびCTLSDatagramHandshake構造体によって定義されます。
Any handshake type registered in the IANA TLS HandshakeType Registry can be conveyed in a CTLS[Datagram]Handshake, but not all messages are actually allowed on a given connection. This definition shows the messages types supported in CTLSHandshake as of TLS 1.3 and DTLS 1.3, but any future message types are also permitted.
IANA TLSハンドシェークタイプレジストリに登録されているハンドシェイクタイプは、CTLS [datagram]ハンドシェイクで伝達できますが、すべてのメッセージが実際に特定の接続で許可されているわけではありません。この定義は、TLS 1.3およびDTLS 1.3の時点でCTLShandshakeでサポートされているメッセージタイプを示していますが、将来のメッセージタイプも許可されています。
struct {
HandshakeType msg_type; /* handshake type */
select (CTLSHandshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; /* New */
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
case request_connection_id: RequestConnectionId;
case new_connection_id: NewConnectionId;
};
} CTLSHandshake;
struct {
HandshakeType msg_type; /* handshake type */
uint16 message_seq; /* DTLS-required field */
select (CTLSDatagramHandshake.msg_type) {
... /* same as CTLSHandshake */
};
} CTLSDatagramHandshake;
Each CTLSHandshake or CTLSDatagramHandshake MUST be conveyed as a single CTLSClientPlaintext.fragment, CTLSServerPlaintext.fragment, or CTLSCiphertext.encrypted_record, and is therefore limited to a maximum length of 2^16-1 or less. When operating over UDP, large CTLSDatagramHandshake messages will also require the use of IP fragmentation, which is sometimes undesirable. Operators can avoid these concerns by setting template.handshakeFraming = true.
各ctlshandshakeまたはctlsdatagramhandshakeは、単一のctlsclientplaintext.fragment、ctlsserverplaintext.fragment、またはctlsciphertext.encrypted_recordとして伝達する必要があります。UDPを介して動作する場合、大規模なCTLSDATAGRAMHHANDSHAKEメッセージには、IPフラグメンテーションの使用も必要になります。オペレーターは、テンプレートを設定することにより、これらの懸念を回避できます。HandshakeFraming= true。
On unreliable transports, the DTLS 1.3 ACK system is used.
信頼できない輸送では、DTLS 1.3 ACKシステムが使用されます。
TLS and DTLS start the handshake with an empty transcript. cTLS is different: it starts the transcript with a "virtual message" whose HandshakeType is ctls_template (Section 6.3) containing the CTLSTemplate used for this connection. This message is included in the transcript even though it is not exchanged during connection setup, in order to ensure that both parties are using the same template. Subsequent messages are appended to the transcript as usual.
TLSとDTLSは、空の転写産物で握手を開始します。CTLSは異なります。この接続に使用されるCTLSTEMプレートを含むHandShakeTypeがCTLS_TEMPLATE（セクション6.3）である「仮想メッセージ」でトランスクリプトを開始します。このメッセージは、両方の当事者が同じテンプレートを使用していることを確認するために、接続セットアップ中に交換されていない場合でも、トランスクリプトに含まれています。後続のメッセージは、通常どおりトランスクリプトに追加されます。
When computing the handshake transcript, all handshake messages are represented in TLS Handshake messages, as in DTLS 1.3 ([RFC9147], Section 5.2), regardless of template.handshake_framing.
ハンドシェイクトランスクリプトを計算するとき、すべての握手メッセージは、TLS 1.3（[RFC9147]、セクション5.2）のように、TLSハンドシェイクメッセージで表されます。
To ensure that all parties agree about what protocol is in use, and whether records are subject to loss, the Cryptographic Label Prefix used for the handshake SHALL be "Sctls " (for "Stream cTLS") if Handshake or CTLSHandshake transport was used, and "Dctls " (for "Datagram cTLS") otherwise. (This is similar to the prefix substitution in Section 5.9 of [RFC9147]).
すべての関係者がプロトコルが使用しているもの、およびレコードが損失の対象かどうかについて確実に同意するために、握手に使用される暗号化ラベルプレフィックスは、ハンドシェイクまたはCTLShandshake輸送を使用した場合、「SCTLS」（「ストリームCTL」の場合）でなければなりません。それ以外の場合は、「dctls」（「datagram ctls」の場合）。（これは、[RFC9147]のセクション5.9のプレフィックス置換に似ています）。
The logical handshake layer consists of handshake messages that are reconstructed following the instructions in the template. At this layer, predefined extensions are reintroduced, truncated Random values are extended, and all information is prepared to enable the cryptographic handshake and any import or export of key material and configuration.
論理的な握手層は、テンプレートの命令に従って再構築される握手メッセージで構成されています。このレイヤーでは、事前定義された拡張機能が再導入され、切り捨てられたランダム値が拡張され、すべての情報が暗号化の握手と主要な材料と構成のインポートまたはエクスポートを可能にするために準備されます。
There is no obligation to reconstruct logical handshake messages in any specific format, and client and server do not need to agree on the precise representation of these messages, so long as they agree on their logical contents.
特定の形式で論理的なハンドシェイクメッセージを再構築する義務はなく、クライアントとサーバーは、これらのメッセージの正確な表現に合意する必要はありません。
In general, we retain the basic structure of each individual TLS or DTLS handshake message. However, the following handshake messages have been modified for space reduction and cleaned up to remove pre-TLS 1.3 baggage.
一般に、個々のTLSまたはDTLSハンドシェイクメッセージの基本構造を保持します。ただし、次の握手メッセージはスペースの削減のために変更され、TLS 1.3の手荷物を削除するためにクリーンアップされました。
The cTLS ClientHello is defined as follows.
CTLS ClientHelloは次のように定義されています。
opaque Random[RandomLength]; // variable length
不透明なランダム[randomLength];//可変長
struct {
Random random;
CipherSuite cipher_suites<1..2^16-1>;
Extension extensions<1..2^16-1>;
} ClientHello;
We redefine ServerHello in the following way.
次の方法でserverhelloを再定義します。
struct {
Random random;
CipherSuite cipher_suite;
Extension extensions<1..2^16-1>;
} ServerHello;
In cTLS, the HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello. The HelloRetryRequest has the following format.
CTLSでは、helloretryrequestメッセージは、serverhelloの専門化ではなく、真の握手メッセージです。HelloretryRequestには次の形式があります。
struct {
CipherSuite cipher_suite;
Extension extensions<2..2^16-1>;
} HelloRetryRequest;
The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value.
HelloretryRequestは、上記のServerHelloと同じですが、不要なセンチネルランダム値はありません。
OPEN ISSUE: Should we define a hello_retry_request_extensions template element? Or is this too far off the happy path to be worth optimizing?
OPENの問題：hello_retry_request_extensionsテンプレート要素を定義する必要がありますか？それとも、これは最適化する価値があるために幸せな道から遠すぎますか？
This section provides some example specializations.
このセクションでは、いくつかの例の専門化を示します。
For this example we use TLS 1.3 only with AES_GCM, x25519, ALPN h2, short random values, and everything else is ordinary TLS 1.3.
この例では、AES_GCM、X25519、ALPN H2、短いランダム値でのみTLS 1.3を使用し、他のすべては通常のTLS 1.3です。
{
"ctlsVersion": 0,
"profile": "0504030201",
"version" : 772,
"random": 16,
"cipherSuite" : "TLS_AES_128_GCM_SHA256",
"dhGroup": {
"groupName": "x25519",
"keyShareLength": 32
},
"clientHelloExtensions": {
"predefinedExtensions": {
"application_layer_protocol_negotiation" : "030016832",
},
"allowAdditional": true
}
}
Version 772 corresponds to the hex representation 0x0304 (i.e. 1.3).
The use of key ids is a new feature introduced in this document, which requires some analysis, especially as it looks like a potential source of identity misbinding. This is, however, entirely separable from the rest of the specification.
キーIDの使用は、このドキュメントで導入された新機能であり、特にアイデンティティの誤型の潜在的なソースのように見えるため、いくつかの分析が必要です。ただし、これは他の仕様から完全に分離可能です。
Once the handshake has completed, this specification is intended to provide a fully secured connection even if the client initially learned the template through an untrusted channel. However, this security relies on the use of a cryptographically strong Finished message. If the Finished message has not yet been received, or the transcript hash has been truncated by use of a small finished_size template element value, an attacker could be using a forged template to impersonate the other party. This should not impact any ordinary use of TLS, including Early Data (which is secured by the previously completed handshake).
握手が完了すると、この仕様は、クライアントが最初にトラストされていないチャネルを介してテンプレートを学習した場合でも、完全に安全な接続を提供することを目的としています。ただし、このセキュリティは、暗号的に強力な完成したメッセージの使用に依存しています。完成したメッセージがまだ受信されていない場合、または小さなfinding_sizeテンプレート要素値を使用してトランスクリプトハッシュが切り捨てられている場合、攻撃者は偽造テンプレートを使用して相手になりすましている可能性があります。これは、初期のデータ（以前に完了した握手によって保護されている）を含むTLSの通常の使用に影響を与えるものではありません。
This document requests that a code point be allocated from the "TLS ContentType registry. This value must be in the range 0-31 (inclusive). The row to be added in the registry has the following form:
このドキュメントは、コードポイントを「TLS ContentTypeレジストリから割り当てることを要求します。この値は0-31（包括的）の範囲にある必要があります。レジストリに追加する行には次の形式があります。
+=======+================+=========+===========+
| Value | Description | DTLS-OK | Reference |
+=======+================+=========+===========+
| TBD | ctls | Y | RFCXXXX |
+-------+----------------+---------+-----------+
| TBD | ctls_handshake | Y | RFCXXXX |
+-------+----------------+---------+-----------+
Table 1
表1
RFC EDITOR: Please replace the value TBD with the value assigned by IANA, and the value XXXX to the RFC number assigned for this document.
RFCエディター：値TBDをIANAによって割り当てられた値を、このドキュメントに割り当てられたRFC番号に値xxxxを置き換えてください。
This document requests that IANA open a new registry entitled "cTLS Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents:
このドキュメントは、IANAが「CTLSテンプレートキー」というタイトルの新しいレジストリを開くことを要求します。TransportLayer Security（TLS）パラメーターページで、「仕様が必要」登録ポリシーと次の初期内容を備えています。
+================================+=======+=================+
| Name | Value | Reference |
+================================+=======+=================+
| profile | 0 | (This document) |
+--------------------------------+-------+-----------------+
| version | 1 | (This document) |
+--------------------------------+-------+-----------------+
| cipher_suite | 2 | (This document) |
+--------------------------------+-------+-----------------+
| dh_group | 3 | (This document) |
+--------------------------------+-------+-----------------+
| signature_algorithm | 4 | (This document) |
+--------------------------------+-------+-----------------+
| random | 5 | (This document) |
+--------------------------------+-------+-----------------+
| mutual_auth | 6 | (This document) |
+--------------------------------+-------+-----------------+
| handshake_framing | 7 | (This document) |
+--------------------------------+-------+-----------------+
| client_hello_extensions | 8 | (This document) |
+--------------------------------+-------+-----------------+
| server_hello_extensions | 9 | (This document) |
+--------------------------------+-------+-----------------+
| encrypted_extensions | 10 | (This document) |
+--------------------------------+-------+-----------------+
| certificate_request_extensions | 11 | (This document) |
+--------------------------------+-------+-----------------+
| known_certificates | 12 | (This document) |
+--------------------------------+-------+-----------------+
| finished_size | 13 | (This document) |
+--------------------------------+-------+-----------------+
| optional | 65535 | (This document) |
+--------------------------------+-------+-----------------+
Table 2
表2
IANA is requested to add the following entry to the TLS HandshakeType registry.
IANAは、TLSハンドシェークタイプレジストリに次のエントリを追加するように要求されます。
* Value: TBD
* 値：TBD
* Description: ctls_template
* 説明：CTLS_TEMPLATE
* DTLS-OK: Y
* dtls-ok：y
* Reference: (This document)
* 参照：（このドキュメント）
* Comment: Virtual message used in cTLS.
* コメント：CTLSで使用される仮想メッセージ。
This document requests that IANA change the name of entry 6 in the TLS HandshakeType Registry from "hello_retry_request_RESERVED" to "hello_retry_request", and set its Reference field to this document.
このドキュメントは、IANAがTLS HandShakeTypeレジストリのエントリ6の名前を「hello_retry_request_reserved」から「hello_retry_request」に変更し、その参照フィールドをこのドキュメントに設定することを要求します。
This document requests that IANA open a new registry entitled "Well-known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns:
このドキュメントは、IANAが「有名なCTLSプロファイルID」というタイトルの新しいレジストリを開くことを要求します。トランスポートレイヤーセキュリティ（TLS）パラメーターページで、次の列があります。
* ID value: A sequence of 1-4 octets.
* ID値：1〜4オクテットのシーケンス。
* Template: A JSON object.
* テンプレート：JSONオブジェクト。
* Note: An explanation or reference.
* 注：説明または参照。
The ID values of length 1 are subject to a "Standards Action" registry policy. Values of length 2 are subject to an "RFC Required" policy. Values of length 3 and 4 are subject to a "First Come First Served" policy. Values longer than 4 octets are not subject to registration and MUST NOT appear in this registry.
長さ1のID値は、「標準アクション」レジストリポリシーの対象となります。長さ2の値は、「RFCが必要」ポリシーの対象となります。長さ3と4の値は、「最初に来る」ポリシーの対象となります。4オクテットより長い値は登録の対象ではなく、このレジストリに表示されてはなりません。
The initial registry contents are:
最初のレジストリコンテンツは次のとおりです。
+==========+==================+===============+
| ID value | Template | Note |
+==========+==================+===============+
| [0x00] | {"version": 772} | cTLS 1.3-only |
+----------+------------------+---------------+
Table 3
表3
[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/rfc/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/rfc/RFC2119>。
[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/rfc/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの小文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/rfc/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/rfc/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/rfc/RFC846>
[RFC9147] 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/rfc/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/rfc/rfc9147>。
[Comparse] Wallez, T., Protzenko, J., and K. Bhargavan, "Comparse: Provably Secure Formats for Cryptographic Protocols", 2023, <https://eprint.iacr.org/2023/1390>.
[比較] Wallez、T.、Protzenko、J。、およびK. Bhargavan、「比較：暗号化プロトコル用の証拠的に安全な形式」、2023、<https://eprint.iacr.org/2023/1390>。
The follow exchange illustrates a complete cTLS-based exchange supporting mutual authentication using certificates. The digital signatures use Ed25519. The ephemeral Diffie-Hellman uses the X25519 curve and the exchange negotiates TLS-AES-128-CCM8-SHA256. The certificates are exchanged using certificate identifiers.
フォローエクスチェンジは、証明書を使用した相互認証をサポートする完全なCTLSベースの交換を示しています。デジタル署名はED25519を使用しています。Ephemeral Diffie-HellmanはX25519曲線を使用し、交換はTLS-AS-128-CCM8-SHA256を交渉します。証明書は、証明書識別子を使用して交換されます。
The resulting byte counts are as follows:
結果のバイト数は次のとおりです。
ECDHE
------------------
TLS CTLS Cryptovariables
--- ---- ---------------
ClientHello 132 74 64
ServerHello 90 68 64
ServerFlight 478 92 72
ClientFlight 458 91 72
========================================
Total 1158 325 272
The following compression profile was used in this example:
この例では、次の圧縮プロファイルが使用されました。
{
"ctlsVersion": 0,
"profile": "abcdef1234",
"version": 772,
"cipherSuite": "TLS_AES_128_CCM_8_SHA256",
"dhGroup": {
"groupName": "x25519",
"keyShareLength": 32
},
"signatureAlgorithm": {
"signatureScheme": "ed25519",
"signatureLength": 64
},
"finishedSize": 8,
"clientHelloExtensions": {
"predefinedExtensions": {
"server_name": "000e00000b6578616d706c652e636f6d"
},
"expectedExtensions": ["key_share"],
"allowAdditional": false
},
"serverHelloExtensions": {
"expectedExtensions": ["key_share"],
"allowAdditional": false
},
"encryptedExtensions": {
"allowAdditional": false
},
"mutualAuth": true,
"knownCertificates": {
"61": "3082...",
"62": "3082...",
"63": "...",
"64": "...",
...
}
}
ClientHello: 74 bytes = Profile ID(5) + Random(32) + DH(32) +
Overhead(5)
$TBD // CTLSClientPlaintext.message_type = ctls_handshake
05 abcdef1234 // CTLSClientPlaintext.profile_id
0041 // CTLSClientPlaintext.fragment length = 65
01 // CTLSHandshake.msg_type = client_hello
5856...c130 // ClientHello.random (32 bytes)
// ClientHello.extensions is omitted except for the key share contents.
a690...f948 // KeyShareEntry.key_exchange (32 bytes)
ServerHello: 68 bytes = Random(32) + DH(32) + Overhead(4)
$TBD // CTLSServerPlaintext.message_type = ctls_handshake 0041 // CTLSServerPlaintext.fragment length 02 // CTLSHandshake.msg_type = server_hello cff4...9ca8 // ServerHello.random (32 bytes) // ServerHello.extensions is omitted except for the key share contents. 9fbc...0f49 // KeyShareEntry.key_exchange (32 bytes)
$ tbd // ctlsserverplaintext.message_type = ctls_handshake 0041 // ctlsserverplaintext.fragment length 02 // ctlshandshake.msg_type = server_hello cff4 ...コンテンツ。9FBC ... 0f49 // keyshareentry.key_exchange（32バイト）
Server Flight: 92 = SIG(64) + Finished(8) + MAC(8) + CERTID(1) +
Overhead(11)
24 // CTLSCipherText header, L=1, C,S,E=0
0059 // CTLSCipherText.length = 89
// BEGIN ENCRYPTED CONTENT
//暗号化されたコンテンツを開始します
08 // CTLSHandshake.msg_type = encrypted_extensions
08 // ctlshandshake.msg_type = necrypted_extensions
// The EncryptedExtensions body is omitted because there are no more
// extensions. The length is also omitted, because allowAdditional is
// false.
// The CertificateRequest message is omitted because "mutualAuth" and // "signatureAlgorithm" are specified in the template.
//「MutualAuth」と//「SignatureAlgorithm」がテンプレートで指定されているため、CertificateRequestメッセージは省略されています。
0b // CTLSHandshake.msg_type = certificate
00 // Certificate.certificate_request_context = ""
03 // Certificate.certificate_list length
01 // CertificateEntry.cert_data length
61 // cert_data = 'a'
00 // CertificateEntry.extensions
0f // CTLShandshake.msg_type = certificate_verify 3045...10ce // CertificateVerify.signature
0f // ctlshandshake.msg_type = certificate_verify 3045 ... 10ce // cermosterverify.signature
14 // CTLSHandshake.msg_type = finished bfc9d66715bb2b04 // Finished.verify_data
14 // ctlshandshake.msg_type = finent bfc9d66715bb2b04 // finited.verify_data
// END ENCRYPTED CONTENT
//暗号化されたコンテンツを終了します
b3d9...0aa7 // CCM-8 MAC (8 bytes)
B3D9 ... 0AA7 // CCM-8 MAC（8バイト）
Client Flight: 91 bytes = SIG(64) + Finished(8) + MAC(8) + CERTID(1)
+ Overhead(10)
24 // CTLSCipherText header, L=1, C,S,E=0
0058 // CTLSCipherText.length = 88
// BEGIN ENCRYPTED CONTENT
//暗号化されたコンテンツを開始します
0b // CTLSHandshake.msg_type = certificate
00 // Certificate.certificate_request_context = ""
03 // Certificate.certificate_list length
01 // CertificateEntry.cert_data length
62 // cert_data = 'b'
00 // CertificateEntry.extensions
0f // CTLSHandshake.msg_type = certificate_verify // CertificateVerify.algorithm is omitted // CertificateVerify.signature length is omitted 3045...f60e // CertificateVerify.signature (64 bytes)
0f // ctlshandshake.msg_type = certificate_verify // cermogterverify.algorithmは省略// cermosterverify.signatureの長さ3045 ... f60e // cermosterverify.signature（64バイト）
14 // CTLSHandshake.msg_type = finished 35e9c34eec2c5dc1 // Finished.verify_data
14 // ctlshandshake.msg_type =完成35e9c34eec2c5dc1 // finited.verify_data
// END ENCRYPTED CONTENT
//暗号化されたコンテンツを終了します
09c5..37b1 // CCM-8 MAC (8 bytes)
09C5..37B1 // CCM-8 MAC（8バイト）
Acknowledgments
謝辞
We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean Turner, Martin Thomson, Chris Wood, Theophile Wallez, and John Preu Mattsson.
Karthikeyan Bhargavan、Owen Friel、Sean Turner、Martin Thomson、Chris Wood、Theophile Wallez、John Preu Mattssonに感謝します。
Authors' Addresses
著者のアドレス
Eric Rescorla Windy Hill Systems, LLC Email: ekr@rtfm.com
Eric Rescorla Windy Hill Systems、LLCメール：ekr@rtfm.com
Richard Barnes Cisco Email: rlb@ipv.sx
リチャードバーンズシスコメール：rlb@ipv.sx
Hannes Tschofenig Email: hannes.tschofenig@gmx.net
hannes tschofenigメール：hannes.tschofenig@gmx.net
Benjamin M. Schwartz Google Email: ietf@bemasc.net
Benjamin M. Schwartz Googleメール：ietf@bemasc.net
Rescorla, et al. Expires 25 April 2024 [Page 26]
Rescorla、et al。2024年4月25日に期限切れ[26ページ]