draft-ietf-tls-tlsflags-10 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-10
タイトル : RFC draft-ietf-tls-tlsflags-10
翻訳編集 : 自動生成

現在表示しているRFCはDraft版です。

TLS                                                               Y. Nir
Internet-Draft                                         Dell Technologies
Intended status: Standards Track                            26 July 2022
Expires: 27 January 2023

A Flags Extension for TLS 1.3 draft-ietf-tls-tlsflags-10

TLS 1.3 Draft-ITF-TLS-TLSFLAGS-10のフラグエクステンション

Abstract

概要

A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8.

TLSワーキンググループでは、特定のオプション機能がサポートされているという1ビットの表示を除いて、興味深い情報を持たない多くの拡張機能が提案されています。このような拡張機能は、それぞれ4オクテットを取ります。このドキュメントでは、それぞれ1ビットの平均限界コストでそのような適応症を提供できるフラグ拡張機能を定義します。より正確には、最後のセットビットの順序を8で割った4時に、必要な数のフラグ拡張機能を提供します。

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 27 January 2023.

このインターネットドラフトは、2023年1月27日に期限切れになります。

著作権表示

著作権（c）2022 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements and Other Notation . . . . . . . . . . . . .   3
   2.  The tls_flags Extension . . . . . . . . . . . . . . . . . . .   3
   3.  Rules for The Flags Extension . . . . . . . . . . . . . . . .   4
     3.1.  Interaction with the 0-RTT Handshake  . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

Since the publication of TLS 1.3 ([RFC8446]) there have been several proposals for extensions to this protocol, where the presence of the content-free extension in both the ClientHello and either the ServerHello or EncryptedExtensions indicates nothing except either support for the optional feature or an intent to use the optional feature. Examples:

TLS 1.3（[rfc8446]）の公開以来、このプロトコルの拡張に関するいくつかの提案があります。このプロトコルでは、clienthelloとserverhelloまたは暗号化されたテクステンションの両方でコンテンツフリーの拡張機能の存在は、オプションの機能のサポートを除いて何も示しません。または、オプションの機能を使用する意図。例：

* An extension that allows the server to tell the client that cross-SNI resumption is allowed: [I-D.sy-tls-resumption-group].

* サーバーがクライアントにCross-SNI再開が許可されていることをクライアントに伝えることを可能にする拡張機能：[i-d.sy-tls-resumption-group]。

* An extension that is used to negotiate support for authentication using both certificates and external PSKs: [I-D.ietf-tls-tls13-cert-with-extern-psk].

* 証明書と外部PSKの両方を使用して認証のサポートを交渉するために使用される拡張機能：[i-d.ietf-tls-tls13-cert-with-extern-psk]。

* The post_handshake_auth extension from the TLS 1.3 base document indicates that the client is willing to perform post-handshake authentication.

* TLS 1.3ベースドキュメントからのPOST_HANDSHAKE_AUTH拡張機能は、クライアントがポストハンドシェイク認証を実行する意思があることを示しています。

This document proposes a single extension called tls_flags that can enumerate such flag extensions and allowing both client and server to indicate support for optional features in a concise way.

このドキュメントでは、このようなフラグ拡張機能を列挙し、クライアントとサーバーの両方が簡潔な方法でオプション機能のサポートを示すことができるTLS_FLAGSと呼ばれる単一の拡張機能を提案します。

None of the current proposed extensions allow for indication of support in ServerHello (SH), EncryptedExtensions (EE), Certificate (CT), or HelloRetryRequest (HRR) without first being indicated in ClientHello (CH). Similarly, none of the current proposed extensions allow for an indication of support in the client-side Certificate (CT) message without first being indicated in the server's CertificateRequest (CR) message. This restriction is enforced by the rules in Section 3.

現在提案されている拡張機能のいずれも、ServerHello（SH）、暗号化されたテクステン（EE）、証明書（CT）、またはHelloretryRequest（HRR）でのサポートの表示を許可していません。同様に、現在提案されている拡張機能のいずれも、サーバーの証明書（CR）メッセージに最初に示されることなく、クライアント側の証明書（CT）メッセージのサポートを示すことはできません。この制限は、セクション3の規則によって実施されます。

1.1. Requirements and Other Notation

1.1. 要件およびその他の表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14 [RFC2119] [RFC8174]に記載されているように解釈されると、ここに示すように、すべての首都に表示されます。

The term "flag extension" is used to denote an extension where the extension_data field is always zero-length in a particular context, and the presence of the extension denotes either support for some feature or the intent to use that feature.

「フラグ拡張」という用語は、特定のコンテキストでextension_Dataフィールドが常にゼロ長である拡張機能を示すために使用され、拡張機能の存在は、いくつかの機能のサポートまたはその機能を使用する意図のいずれかを示します。

The term "flag-type feature" denotes an options TLS 1.3 feature the support for which is negotiated using a flag extension, whether that flag extension is its own extension or a value in the extension defined in this document.

「フラグタイプの機能」という用語は、Flag拡張子が独自の拡張機能であるか、このドキュメントで定義されている拡張機能の値であろうと、FLAG拡張機能を使用してネゴシエートされるオプションTLS 1.3機能を示します。

2. The tls_flags Extension

2. TLS_FLAGS拡張機能

This document defines the following extension code point:

このドキュメントは、次の拡張コードポイントを定義します。

      enum {
         ...
         tls_flags(TBD),
         (65535)
      } ExtensionType;

This document also defines the data for this extension as a variable-length bit string, allowing for the encoding of up to 2040 features.

このドキュメントでは、この拡張子のデータを可変長ビット文字列として定義し、最大2040の機能をエンコードできるようにします。

      struct {
         opaque flags<1..255>;
      } FlagExtensions;

The FlagExtensions field contains 8 flags in each octet. The length of the extension is the minimal length that allows it to encode all of the present flags. Within each octet, the bits are packed such that the first bit is the least significant bit and the eighth bit is

Flagextensionsフィールドには、各オクテットに8つのフラグが含まれています。拡張の長さは、現在のすべてのフラグをエンコードできる最小の長さです。各オクテット内で、ビットは詰め込まれているため、最初のビットが最も重要なビットであり、8番目のビットは

the most significant. Using zero-based indexing, the first octet holds flags 0-7, the second octet holds bits 8-15 and so on. For example, if we want to encode only flag number zero, the FlagExtension field will be 1 octet long, that is encoded as follows:

最も重要です。ゼロベースのインデックス作成を使用して、最初のオクテットにはフラグが0〜7、2番目のオクテットには8〜15枚などがあります。たとえば、フラグ番号ゼロのみをエンコードする場合、Flagextensionフィールドは1オクテットの長さで、次のようにエンコードされます。

00000001

If we want to encode flags 1 and 5, the field will still be 1 octet long:

フラグ1と5をエンコードしたい場合、フィールドはまだ1オクテットの長さになります。

00100010

If we want to encode flags 3, 5, and 23, the field will have to be 3 octets long:

フラグ3、5、および23をエンコードする場合、フィールドは3オクテットの長さでなければなりません。

00101000 00000000 10000000

00101000 000000000000000

An implementation that receives an all-zero value for this extension or a value that contains trailing zero bytes MUST generate a fatal illegal_parameter alert.

この拡張機能のすべてのゼロ値を受信する実装または、微細なゼロバイトを含む値は、致命的なIllegal_Parameterアラートを生成する必要があります。

Note that this document does not define any particular bits for this string. That is left to the protocol documents such as the ones in the examples from the previous section. Such documents will have to define which bit to set to show support, and the order of the bits within the bit string shall be enumerated in network order: bit zero is the high-order bit of the first octet as the flags field is transmitted.

このドキュメントは、この文字列の特定のビットを定義していないことに注意してください。これは、前のセクションの例のようなプロトコルドキュメントに任されています。このようなドキュメントは、サポートを表示するために設定するビットを定義する必要があり、ビット文字列内のビットの順序はネットワーク順序で列挙されます。ビットゼロは、フラグフィールドが送信されるため、最初のオクテットの高次ビットです。

3. Rules for The Flags Extension

3. フラグ拡張機能のルール

Any TLS implementation that intends to propose or indicate support for a flag extension SHALL send this extension with the relevant bits set. It MUST NOT send this extension empty -- with a length of zero.

フラグ拡張のサポートを提案または指定する予定のTLS実装は、関連するビットセットでこの拡張機能を送信するものとします。この拡張機能を空にしてはなりません - ゼロの長さ。

This specification does not require every flag extension to be acknowledged. Acknowledging a flag extension is typically needed to inform the peer proposing the extension that the other side understands and supports the extension, but some extensions do not require this acknowledgement.

この仕様では、すべてのフラグ拡張機能を確認する必要はありません。通常、フラグの拡張機能を認めることは、反対側が拡張機能を理解してサポートすることを提案するピアに通知するために必要ですが、一部の拡張はこの承認を必要としません。

For a flag that does require a response, the only proper response is the same flag in a flags extension. This extension MUST NOT be used to specify extensions where the response is a proper extension with content.

応答を必要とするフラグの場合、唯一の適切な応答は、フラグ拡張機能の同じフラグです。この拡張子を使用して、応答がコンテンツの適切な拡張機能である拡張機能を指定するために使用してはなりません。

A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in HelloRetryRequest (HRR) as the corresponding flag document specifies. Similarly, a flag proposed by the server in the CertificateRequest (CR) message that requires acknowledgement SHOULD be acknowledged in the client's Certificate (CT) message. A flag proposed by the server in the NewSessionTicket (NST) message is never acknowledged as there is not client-side response message.

承認を必要とするClientHello（CH）のクライアントが提案したフラグは、serverhello（sh）、暗号化されたテクステンション（EE）、証明書（CT）、または対応するフラグドキュメントが指定するようにHelloretryRequest（HRR）のいずれかで確認する必要があります。同様に、承認を必要とする証明書（CR）メッセージでサーバーによって提案されたフラグは、クライアントの証明書（CT）メッセージで確認される必要があります。NewsessionTicket（NST）メッセージでサーバーによって提案されたフラグは、クライアント側の応答メッセージがないため、決して認められません。

Multiple flags can be proposed or acknowledged in the same extension.

同じ拡張機能で複数のフラグを提案または確認できます。

In all of the above cases, a flag MUST NOT be acknowledged in SH, EE, CT, or HRR without first having been proposed in CH or CR. Unsolicited flags may appear only in CH, CR, and NST. And endpoint that receives an unsolicited flag in another message (HRR, SH, EE, or CT) MUST generate a fatal illegal_parameter alert.

上記のすべてのケースでは、CHまたはCRで最初に提案されずに、SH、EE、CT、またはHRRでフラグを確認してはなりません。未承諾フラグは、CH、CR、およびNSTでのみ表示される場合があります。また、別のメッセージ（HRR、SH、EE、またはCT）で未承諾フラグを受信するエンドポイントは、致命的なIllegal_Parameterアラートを生成する必要があります。

A client that supports this extension and at least one flag extension SHALL send this extension with the flags field having bits set only for those extensions that it intends to set. It MUST NOT send this extension with a length of zero.

この拡張機能と少なくとも1つのフラグ拡張機能をサポートするクライアントは、設定する予定の拡張機能に対してのみ設定されたBITSを持つフラグフィールドでこの拡張機能を送信するものとします。ゼロの長さでこの拡張機能を送信してはなりません。

An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert.

無効なTLS_FLAGS拡張機能を受信する実装は、致命的なIllegal_ParameterアラートでTLSハンドシェイクを終了する必要があります。

3.1. Interaction with the 0-RTT Handshake

3.1. 0-RTTの握手との相互作用

The 0-RTT handshake, defined in section 2.3 of [RFC8446], has a ClientHello message, a ServerHello message, and an EncryptedExtensions message. Those can include the tls_flags extension just as they can in a regular handshake.

[RFC8446]のセクション2.3で定義されている0-RTTハンドシェイクには、ClientHelloメッセージ、ServerHelloメッセージ、および暗号化されたEdextensionsメッセージがあります。これらには、通常の握手でできる限りTLS_FLAGS拡張機能を含めることができます。

Future flag extensions MUST define their interaction with 0-RTT, just as other extensions are required to.

将来のフラグ拡張機能は、他の拡張機能が必要なように、0-RTTとの相互作用を定義する必要があります。

4. IANA Considerations

4. IANAの考慮事項

IANA is requested to assign a new value from the TLS ExtensionType Values registry:

IANAは、TLS ExtensionType値レジストリから新しい値を割り当てるように要求されます。

* The Extension Name should be tls_flags

* 拡張名はtls_flagsである必要があります

* The TLS 1.3 value should be CH,SH,HRR,EE,CR,CT,NST

* TLS 1.3値は、ch、sh、hrr、ee、cr、ct、nstでなければなりません

* The DTLS-Only value should be N

* DTLSのみの値はnでなければなりません

* The Recommended value should be Y

* 推奨される値はyでなければなりません

* The Reference should be this document

* 参照はこのドキュメントである必要があります

IANA is also requested to create a new registry under the TLS namespace with name "TLS Flags" and the following fields:

IANAは、「TLSフラグ」と次のフィールドを備えたTLS名空間の下に新しいレジストリを作成することも要求されています。

* Value, which is a number between 0 and 2039. All potential values are available for assignment.

* 値、これは0から2039の数です。すべての潜在的な値は割り当てに利用可能です。

* Flag Name, which is a string

* 文字列であるフラグ名

* Message, which like the "TLS 1.3" field in the ExtensionType registry contains the abbreviations of the messages that may contain the flag: CH, SH, EE, etc.

* extensionTypeレジストリの「TLS 1.3」フィールドのようなメッセージには、フラグを含む可能性のあるメッセージの略語が含まれています：CH、SH、EEなど。

* Recommended, which is a Y/N value determined in the document defining the optional feature.

* 推奨されます。これは、オプション機能を定義するドキュメントで決定されるY/N値です。

* Reference, which is a link to the document defining this flag.

* 参照。これは、このフラグを定義するドキュメントへのリンクです。

The policy for this shall be "Specification Required" as described in Section 4.6 of [RFC8126] with the exception of flags numbered from 0-15, which follow the "Standards Action" policy (Section 4.9 of [RFC8126]). Designated expert(s) are advised to follow the advice in Section 17 of [RFC8447] when reviewing registration requests.

このポリシーは、[RFC8126]のセクション4.6に記載されているように、「標準アクション」ポリシー（[RFC8126]のセクション4.9）に従う0〜15の数字を除き、[RFC8126]のセクション4.6に記載されているように「必要な仕様」となります。指定された専門家は、登録要求を確認する際に、[RFC8447]のセクション17のアドバイスに従うことをお勧めします。

The initial contents of the registry shall be one entry, as follows:

レジストリの最初の内容は、次のように1つのエントリでなければなりません。

* Value shall be 8

* 値は8でなければならない

* Flag Name shall be resumption_across_names

* フラグ名はresumption_across_namesでなければなりません

* Message shall be NST

* メッセージはNSTでなければなりません

* Recommended shall be set to no (N)

* 推奨されるものはno（n）に設定するものとします

* The reference shall the the RFC-to-be [I-D.ietf-tls-cross-sni-resumption].

* 参照は、rfc-to-be [i-d.ietf-tls-cross-sni-resumption]にするものとします。

5. Security Considerations

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

The extension described in this document provides a more concise way to express data that could otherwise be expressed in individual extensions. It does not send in the clear any information that would otherwise be sent encrypted, nor vice versa. For this reason this extension is neutral as far as security is concerned.

このドキュメントで説明されている拡張機能は、個々の拡張機能で表現できるデータを表現するためのより簡潔な方法を提供します。それ以外の場合は暗号化されたものを送信する情報を明確に送信しません。このため、セキュリティに関する限り、この拡張機能は中立です。

Extension authors should be aware that acknowledging flags in a tls_flags extension of the ServerHello and HelloRetryRequest messages expose this response to passive observers. Unless there is a special reason to place the response in the ServerHello, most flags should go in other (encrypted) messages.

拡張著者は、ServerHelloおよびHelloretryRequestメッセージのTLS_FLAGS拡張機能でフラグを認めることを認識する必要があります。ServerHelloに応答を配置する特別な理由がない限り、ほとんどのフラグは他の（暗号化された）メッセージに移動する必要があります。

6. Acknowledgements

6. 謝辞

The idea for writing this was expressed at the mic during the TLS session at IETF 104 by Eric Rescorla.

これを書くためのアイデアは、エリック・レスコルラによるIETF 104でのTLSセッション中にMICで表現されました。

The current bitwise formatting was suggested on the mailing list by Nikos Mavrogiannopoulos.

現在のビットワイズフォーマットは、Nikos Mavrogiannopoulosによるメーリングリストで提案されました。

Improvement to the encoding were suggested by Ilari Liusvaara, who also asked for a better explanation of the semantics of missing extensions.

エンコードの改善は、Ilari Liusvaaraによって提案されました。IlariLiusvaaraは、欠落している拡張機能のセマンティクスのより良い説明も求めました。

Useful comments received from Martin Thomson, including the suggestion to eliminate the option to have the server send unsolicited flag types and the rules for where unsolicited flags can appear.

Martin Thomsonから受け取った有用なコメント。これには、サーバーに未承諾フラグの種類を送信させるオプションと、未承諾フラグが表示される場所のルールを排除するという提案が含まれます。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、DOI 10.17487/RFC2119、BCP 14、RFC 2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。

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

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、DOI 10.17487/RFC8174、RFC 8174、BCP 14、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。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>

[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. Turner、「TLSおよびDTLSのIANAレジストリの更新」、RFC 8447、DOI 10.17487/RFC8447、2018年8月、<https://www.rfc-editor.org/info/rfc8447>。

7.2. Informative References

7.2. 参考引用

[I-D.ietf-tls-cross-sni-resumption] Vasiliev, V., "Transport Layer Security (TLS) Resumption across Server Names", Work in Progress, Internet-Draft, draft-ietf-tls-cross-sni-resumption-02, 5 December 2021, <https://www.ietf.org/archive/id/draft-ietf-tls-cross-sni-resumption-02.txt>.

[i-d.ietf-tls-cross-sni-resumption] vasiliev、v。、「サーバー名を横切る輸送層のセキュリティ（TLS）再開」、進行中の作業、インターネットドラフト、ドラフト-TLS-CROSS-SNI-Resumption-02、2021年12月5日、<https://www.ietf.org/id/draft-ietf-tls-cross-sni-sni-sumption-02.txt>。

[I-D.ietf-tls-tls13-cert-with-extern-psk] Housley, R., "TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key", Work in Progress, Internet-Draft, draft-ietf-tls-tls13-cert-with-extern-psk-07, 23 December 2019, <https://www.ietf.org/archive/id/draft-ietf-tls-tls13- cert-with-extern-psk-07.txt>.

[i-d.ietf-tls-tls13-cert-with-extern-psk] Housley、R。、「TLS 1.3外部の事前共有キーを使用した証明書ベースの認証のための拡張」、進行中の作業、インターネットドラフト、ドラフト - ietf-tls-tls13-cert-with-extern-psk-07、2019年12月23日、<https://www.ietf.org/id/draft-ietf-tls-tls13- cert-with-extern-psk-07.txt>。

[I-D.sy-tls-resumption-group] Sy, E., "TLS Resumption across Server Name Indications for TLS 1.3", Work in Progress, Internet-Draft, draft-sy-tls-resumption-group-00, 1 March 2019, <https://www.ietf.org/archive/id/draft-sy-tls-resumption-group-00.txt>.

[i-d.sy-tls-resumption-group] sy、E。、「TLS 1.3のサーバー名の適応症にわたるTLS再開」、進行中の作業、インターネットドラフト、Draft-SY-TLS-Resumption-Group-00、3月1日2019、<https://www.ietf.org/archive/id/draft-sy-tls-resumption-group-00.txt>。

[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <https://www.rfc-editor.org/info/rfc5746>.

[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「輸送層のセキュリティ（TLS）再交渉の表示拡張」、RFC 5746、DOI 10.17487/RFC5746、2010年2月、<HTTPS：//www.rfc-editor.org/info/rfc5746>。

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

[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、RFC 8126、DOI 10.17487/RFC8126、BCP 26、2017年6月、<https：// wwwwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。

Appendix A. Change Log

付録A. ログを変更します

RFC EDITOR: PLEASE REMOVE THIS SECTION AS IT IS ONLY MEANT TO AID THE WORKING GROUP IN TRACKING CHANGES TO THIS DOCUMENT.

RFCエディター：このセクションは、ワーキンググループがこのドキュメントの変更を追跡するのを支援することのみを目的としているため、削除してください。

draft-ietf-tls-tlsflags-02 set the maximum number of flags to 2048, and added guidance for the IANA experts.

Draft-ITETF-TLS-TLSFLAGS-02は、フラグの最大数を2048に設定し、IANAの専門家にガイダンスを追加しました。

draft-ietf-tls-tlsflags-01 allows server-only flags and allows the client to send an empty extension. Also modified the packing order of the bits.

Draft-ITETF-TLS-TLSFLAGS-01は、サーバーのみのフラグを許可し、クライアントが空の拡張機能を送信できるようにします。また、ビットの梱包順序も変更しました。

draft-ietf-tls-tlsflags-00 had the same text as draft-nir-tls-tlsflags-02, and was re-submitted as a working group document following the adoption call.

Draft-ITETF-TLS-TLSFLAGS-00は、Draft-NIR-TLS-TLSFLAGS-02と同じテキストを持ち、採用コールに続いてワーキンググループ文書として再提出されました。

Version -02 replaced the fixed 64-bit string with an unlimited bitstring, where only the necessary octets are encoded.

バージョン-02は、固定された64ビット文字列を無制限のビットストリングに置き換えました。ここでは、必要なオクテットのみがエンコードされています。

Version -01 replaced the enumeration of 8-bit values with a 64-bit bitstring.

バージョン-01は、8ビット値の列挙を64ビットのビットストリングに置き換えました。

Version -00 was a quickly-thrown-together draft with the list of supported features encoded as an array of 8-bit values.

バージョン-00は、8ビット値の配列としてエンコードされたサポートされている機能のリストを備えた、迅速に投げられたドラフトでした。

Author's Address

著者の連絡先

Yoav Nir Dell Technologies 9 Andrei Sakharov St Haifa 3190500 Israel Email: ynir.ietf@gmail.com

Yoav Nir Dell Technologies 9 Andrei Sakharov St Haifa 3190500 Israel Email：ynir.ietf@gmail.com