RFC 9848 - Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9848.html
タイトル : RFC 9848 - DNS サービスバインディングを使用した TLS 暗号化 ClientHello (ECH) のブートストラップ
翻訳編集 : 自動生成

[要約] DNSのSVCBおよびHTTPSレコードにおいて、TLS Encrypted ClientHello (ECH) の構成情報を伝達するための新しいSvcParam「ech」を定義しています。クライアントがサーバーへの接続を試行する前にDNS経由でECH構成を学習できるようにすることで、TLS接続のブートストラップを可能にします。プライバシー保護を最大化しダウングレード攻撃を防ぐための、サーバーの展開要件とクライアントの実装要件を規定しています。

Internet Engineering Task Force (IETF)                       B. Schwartz
Request for Comments: 9848                          Meta Platforms, Inc.
Category: Standards Track                                      M. Bishop
ISSN: 2070-1721                                                E. Nygren
                                                     Akamai Technologies
                                                              March 2026

Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

DNS サービスバインディングを使用した TLS 暗号化 ClientHello のブートストラップ

Abstract

概要

To use TLS Encrypted ClientHello (ECH), the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR).

TLS 暗号化 ClientHello (ECH) を使用するには、クライアントはサーバーへの接続を試行する前にサーバーの ECH 構成を学習する必要があります。この仕様は、SVCB または HTTPS リソースレコード (RR) を使用して、DNS 経由で ECH 構成情報を伝達するメカニズムを提供します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはインターネット標準化トラックの文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。

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

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

Copyright Notice

著作権表示

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

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

   1.  Overview
   2.  Terminology
   3.  SvcParam for ECH Configuration
   4.  Requirements for Server Deployments
   5.  Requirements for Client Implementations
     5.1.  Disabling Fallback
     5.2.  ClientHello Construction
     5.3.  Performance Optimizations
   6.  Interaction with HTTP Alt-Svc
   7.  Examples
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Authors' Addresses

1. Overview

1. 概要

The Service Bindings framework [SVCB] allows server operators to publish a detailed description of their service in the Domain Name System (DNS) (see [RFC1034] and [BCP219]) using SVCB or HTTPS records. Each SVCB record describes a single "alternative endpoint" and contains a collection of "SvcParams" that can be extended with new kinds of information that may be of interest to a client. Clients can use the SvcParams to improve the privacy, security, and performance of their connection to this endpoint.

サービスバインディングフレームワーク [SVCB] を使用すると、サーバーオペレーターは SVCB または HTTPS レコードを使用して、ドメインネームシステム (DNS) ([RFC1034] および [BCP219] を参照) でサービスの詳細な説明を公開できます。各 SVCB レコードは単一の「代替エンドポイント」を記述し、クライアントにとって興味深い可能性のある新しい種類の情報で拡張できる「SvcParams」のコレクションを含みます。クライアントは SvcParams を使用して、このエンドポイントへの接続のプライバシー、セキュリティ、およびパフォーマンスを向上させることができます。

This specification defines a new SvcParam to enable the use of TLS Encrypted ClientHello [ECH] in TLS-based protocols. This SvcParam can be used in SVCB, HTTPS, or any future SVCB-compatible DNS records and is intended to serve as the primary bootstrap mechanism for ECH.

この仕様では、TLS ベースのプロトコルで TLS 暗号化 ClientHello [ECH] の使用を可能にする新しい SvcParam を定義します。この SvcParam は、SVCB、HTTPS、または将来の SVCB 互換 DNS レコードで使用でき、ECH の主要なブートストラップメカニズムとして機能することを目的としています。

2. Terminology

2. 用語

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

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

3. SvcParam for ECH Configuration

3. ECH 構成用の SvcParam

The "ech" SvcParamKey conveys the ECH configuration of an alternative endpoint. It is applicable to all schemes that use TLS-based protocols (including DTLS [RFC9147] and QUIC version 1 [RFC9001]) unless otherwise specified.

「ech」SvcParamKey は、代替エンドポイントの ECH 構成を伝えます。特に指定がない限り、TLS ベースのプロトコル (DTLS [RFC9147] および QUIC バージョン 1 [RFC9001] を含む) を使用するすべてのスキームに適用されます。

In wire format, the value of the parameter is an ECHConfigList (Section 4 of [ECH]), including the redundant length prefix. In presentation format, the value is the ECHConfigList in Base 64 encoding (Section 4 of [RFC4648]). Base 64 is used here to simplify integration with TLS server software. To enable simpler parsing, this SvcParam MUST NOT contain escape sequences.

ワイヤ形式では、パラメータの値は、冗長長プレフィックスを含む ECHConfigList ([ECH] のセクション 4) です。プレゼンテーション形式では、値は Base 64 エンコーディングの ECHConfigList です ([RFC4648] のセクション 4)。ここでは、TLS サーバーソフトウェアとの統合を簡素化するために Base 64 が使用されています。より単純な解析を可能にするために、この SvcParam にエスケープシーケンスを含めてはなりません。

This example uses line wrapping per [RFC8792].

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

   ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAE\
   AAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="

Figure 1: ECH SvcParam with a public_name of "ech-sites.example.net"

図 1: public_name が「ech-sites.example.net」の ECH SvcParam

4. Requirements for Server Deployments

4. サーバー展開の要件

When publishing a record containing an "ech" parameter, the publisher MUST ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name. (See Sections 6.1.7 and 8.1.1 of [ECH] for requirements related to the public name.) Otherwise, connections will fail entirely.

「ech」パラメータを含むレコードを公開する場合、公開者は、TargetName のすべての IP アドレスが、対応する秘密キーにアクセスできるサーバー、またはパブリック名に対して権限のあるサーバーに対応していることを確認しなければなりません (MUST)。(パブリック名に関する要件については、[ECH] のセクション 6.1.7 および 8.1.1 を参照してください。) そうしないと、接続は完全に失敗します。

These servers SHOULD support a protocol version that is compatible with ECH. At the time of writing, the compatible versions are TLS 1.3, DTLS 1.3, and QUIC version 1. If the server does not support a compatible version, each connection attempt will have to be retried, delaying the connection and wasting resources.

これらのサーバーは、ECH と互換性のあるプロトコルバージョンをサポートする必要があります (SHOULD)。この記事の執筆時点では、互換性のあるバージョンは TLS 1.3、DTLS 1.3、および QUIC バージョン 1 です。サーバーが互換性のあるバージョンをサポートしていない場合は、接続を再試行する必要があり、接続が遅れてリソースが無駄になります。

5. Requirements for Client Implementations

5. クライアント実装の要件

This section describes client behavior in using ECH configurations provided in SVCB or HTTPS records.

このセクションでは、SVCB または HTTPS レコードで提供される ECH 構成を使用するときのクライアントの動作について説明します。

5.1. Disabling Fallback

5.1. フォールバックの無効化

The SVCB-optional client behavior specified in Section 3 of [SVCB] permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH. Accordingly, ECH-capable, SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in Section 3 of [SVCB]) and all alternative endpoints have an "ech" SvcParam.

[SVCB] のセクション 3 で指定されている SVCB オプションのクライアント動作により、すべての SVCB オプションが失敗した場合にクライアントが直接接続にフォールバックすることが許可されます。フォールバックは ECH のプライバシー上の利点を無効にするため、この動作は ECH には適していません。したがって、ECH 対応の SVCB オプションのクライアントは、([SVCB] のセクション 3 で定義されているように) SVCB 解決が成功し、すべての代替エンドポイントが "ech" SvcParam を持っている場合、SVCB に依存した接続確立に切り替えなければなりません (MUST)。

5.2. ClientHello Construction

When ECH is in use, the TLS ClientHello is divided into an unencrypted "outer" and an encrypted "inner" ClientHello. The outer ClientHello is an implementation detail of ECH, and its contents are controlled by the ECHConfig in accordance with [ECH]. The inner ClientHello is used for establishing a connection to the service, so its contents may be influenced by other SVCB parameters. For example, the requirements related to Application-Layer Protocol Negotiation (ALPN) protocol identifiers in Section 7.1.2 of [SVCB] apply only to the inner ClientHello. Similarly, it is the inner ClientHello whose Server Name Indication (SNI) identifies the desired service.

ECH が使用されている場合、TLS ClientHello は、暗号化されていない「外側」の ClientHello と暗号化された「内側」の ClientHello に分割されます。外側の ClientHello は ECH の実装詳細であり、その内容は [ECH] に従って ECHConfig によって制御されます。内部の ClientHello はサービスへの接続を確立するために使用されるため、その内容は他の SVCB パラメーターの影響を受ける可能性があります。たとえば、[SVCB] のセクション 7.1.2 にあるアプリケーション層プロトコルネゴシエーション (ALPN) プロトコル識別子に関連する要件は、内部の ClientHello にのみ適用されます。同様に、これは内部 ClientHello であり、その Server Name Indication (SNI) が目的のサービスを識別します。

5.3. Performance Optimizations

5.3. パフォーマンスの最適化

Prior to retrieving the SVCB records, the client does not know whether they contain an "ech" parameter. As a latency optimization, clients MAY prefetch DNS records that will only be used if this parameter is not present (i.e., only in SVCB-optional mode).

SVCB レコードを取得する前は、クライアントはレコードに「ech」パラメータが含まれているかどうかを知りません。レイテンシの最適化として、クライアントは、このパラメータが存在しない場合 (つまり、SVCB オプションモードでのみ) にのみ使用される DNS レコードをプリフェッチしてもよい(MAY)。

The "ech" SvcParam alters the contents of the TLS ClientHello if it is present. Therefore, clients that support ECH MUST NOT issue any TLS ClientHello until after SVCB resolution has completed. (See Section 5.1 of [SVCB].)

「ech」SvcParam は、TLS ClientHello が存在する場合、その内容を変更します。したがって、ECH をサポートするクライアントは、SVCB 解決が完了するまで TLS ClientHello を発行してはなりません。([SVCB] のセクション 5.1 を参照してください。)

6. Interaction with HTTP Alt-Svc

6. HTTP Alt-Svc との対話

HTTP clients that implement both HTTP Alt-Svc [RFC7838] and the HTTPS record type [SVCB] can use them together, provided that they only perform connection attempts that are "consistent" with both sets of parameters (Section 9.3 of [SVCB]). At the time of writing, there is no defined parameter related to ECH for Alt-Svc. Accordingly, a connection attempt that uses ECH is considered "consistent" with an Alt-Svc field value that does not mention ECH.

HTTP Alt-Svc [RFC7838] と HTTPS レコードタイプ [SVCB] の両方を実装する HTTP クライアントは、両方のパラメータセットと「一貫性のある」接続試行のみを実行するという条件で、それらを一緒に使用できます ([SVCB] のセクション 9.3)。執筆時点では、Alt-Svc の ECH に関連する定義されたパラメーターはありません。したがって、ECH を使用する接続試行は、ECH に言及していない Alt-Svc フィールド値と「一致している」と見なされます。

Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an HTTPS record with the "ech" SvcParam for every alt-authority offered in its Alt-Svc field values. Otherwise, clients might reveal the name of the server in an unencrypted ClientHello to an alt-authority.

HTTPS レコードで「ech」SvcParam を公開するオリジンは、Alt-Svc フィールド値で提供されるすべての alt-authority に対して「ech」SvcParam を含む HTTPS レコードも公開する必要があります (SHOULD)。そうしないと、クライアントが暗号化されていない ClientHello 内のサーバー名を alt-authority に公開する可能性があります。

If all HTTPS records for an alt-authority contain "ech" SvcParams, the client MUST adopt SVCB-reliant behavior (as in Section 5.1) for that resource record set (RRSet). This precludes the use of certain connections that Alt-Svc would otherwise allow, as discussed in Section 9.3 of [SVCB].

alt-authority のすべての HTTPS レコードに「ech」SvcParams が含まれている場合、クライアントはそのリソースレコードセット (RRSet) に対して SVCB に依存した動作 (セクション 5.1 と同様) を採用しなければなりません (MUST)。[SVCB] のセクション 9.3 で説明されているように、これにより、Alt-Svc が許可する特定の接続の使用が妨げられます。

7. Examples

7. 例

   $ORIGIN simple.example. ; Simple example zone
   @ 300 IN A     192.0.2.1
            AAAA  2001:db8::1
            HTTPS 1 . ech=ABC...
   www 300 IN A 192.0.2.1
              AAAA 2001:db8::1
              HTTPS 1 . ech=ABC...

Figure 2: Simple Example Zone with the Same Configuration on the Apex and Web Domain

図 2: Apex ドメインと Web ドメインで同じ構成を持つ単純なゾーンの例

The example above is compatible with clients that do or do not support HTTPS records.

上記の例は、HTTPS レコードをサポートするクライアントとサポートしないクライアントと互換性があります。

   $ORIGIN heterogeneous.example. ; Example zone with 2 pools of servers
   pool1 300 IN    A    192.0.2.1
                   AAAA 2001:db8:1::a
   pool2 300 IN    A    192.0.2.2
                   AAAA 2001:db8:2::a
   service 300 IN SVCB 1 pool1 ech=ABC...
                  SVCB 1 pool2 ech=DEF...
                  A 192.0.2.1
                  A 192.0.2.2
                  AAAA 2001:db8:1::a
                  AAAA 2001:db8:2::a

Figure 3: Service That Allows Clients to Choose Between Two Server Pools with Different ECH Configurations

図 3: クライアントが異なる ECH 構成を持つ 2 つのサーバープールから選択できるサービス

   $ORIGIN cdn.example. ; CDN operator zone
   pool 300 IN A 192.0.2.1
               AAAA 2001:db8::1
               HTTPS 1 . ech=ABC...

   $ORIGIN customer.example. ; CDN customer's zone
   @   3600 IN HTTPS 0 pool.cdn.example.
   ; Apex IP records for compatibility with clients that do not support
   ; HTTPS records.
   @   300  IN A    192.0.2.1
               AAAA 2001:db8::1

   www 300  IN CNAME pool.cdn.example.

Figure 4: ECH Usage Pattern for an Aliasing-Based CDN

図 4: エイリアシングベースの CDN の ECH 使用パターン

   $ORIGIN secret.example. ; High confidentiality zone
   www     3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
   backend 300  IN A     192.0.2.1
                   AAAA  2001:db8::1

Figure 5: A Domain That is Only Reachable Using ECH

図 5: ECH を使用してのみ到達可能なドメイン

   $ORIGIN cdn1.example. ; First CDN operator zone
   pool 300 IN A     192.0.2.1
               AAAA  2001:db8::1
               HTTPS 1 . ech=ABC...

   $ORIGIN cdn2.example. ; Second CDN operator zone
   pool 300 IN A     192.0.2.2
               AAAA  2001:db8::2
               HTTPS 1 . ech=DEF...

   ;; Multi-CDN customer zone (version 1)
   $ORIGIN customer.example.
   @   3600 IN HTTPS 0 pool.cdn1.example.
   ; Apex IP records for compatibility with clients that do not support
   ; HTTPS records.
   @   300  IN A    192.0.2.1
               AAAA 2001:db8::1
   www 3600  IN CNAME pool.cdn1.example.

   ;; Multi-CDN customer zone (version 2)
   @   3600 IN HTTPS 0 pool.cdn2.example.
   @   300  IN A    192.0.2.2
               AAAA 2001:db8::2
   www 3600  IN CNAME pool.cdn2.example.

Figure 6: Multi-CDN Configuration Using Server-Side Selection

図 6: サーバー側の選択を使用したマルチ CDN 構成

   $ORIGIN dns.example. ; DNS server example.
   @    3600 IN A     192.0.2.1
                AAAA  2001:db8::1
                HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns}

   _dns 3600 IN SVCB  1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns}

Figure 7: Example of a DNS Server That Supports ECH

図 7: ECH をサポートする DNS サーバーの例

8. Security Considerations

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

A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: A network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint. This configuration is NOT RECOMMENDED, but it may be unavoidable when combining endpoints from different providers or conducting a staged rollout. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e., lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary.

「ech」を含む RR と含まない RR を含む SVCB RRSet は、ダウングレード攻撃に対して脆弱です。ネットワーク仲介者が ECH をサポートするエンドポイントへの接続をブロックし、クライアントが非 ECH エンドポイントにフォールバックする可能性があります。この構成は推奨されませんが、異なるプロバイダーのエンドポイントを組み合わせたり、段階的なロールアウトを実施したりする場合には避けられない場合があります。このような混合構成を使用するゾーン所有者は、アクティブな敵対者が存在しない場合に ECH が使用される可能性を最大化するために、「ech」を持つ RR を持たない RR よりも優先される (つまり、SvcPriority 値が低い) とマークする必要があります (SHOULD)。

When Encrypted ClientHello is deployed, the inner TLS SNI is protected from disclosure to attackers. However, there are still many ways that an attacker might infer the SNI. Even in an idealized deployment, ECH's protection is limited to an anonymity set consisting of all the ECH-enabled server domains supported by a given client-facing server that share an ECH configuration. An attacker who can enumerate this set can always guess the encrypted SNI with a probability of at least 1/K, where K is the number of domains in the set. Some attackers may achieve much greater accuracy using traffic analysis, popularity weighting, and other mechanisms (e.g., see [CLINIC]).

暗号化された ClientHello が展開されると、内部 TLS SNI は攻撃者への開示から保護されます。ただし、攻撃者が SNI を推測する方法はまだたくさんあります。理想的な展開であっても、ECH の保護は、ECH 構成を共有する特定のクライアント側サーバーによってサポートされるすべての ECH 対応サーバードメインで構成される匿名性セットに限定されます。このセットを列挙できる攻撃者は、常に少なくとも 1/K (K はセット内のドメインの数) の確率で暗号化された SNI を推測できます。一部の攻撃者は、トラフィック分析、人気度の重み付け、およびその他のメカニズムを使用して、より高い精度を達成する可能性があります (例: [CLINIC] を参照)。

ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the server's hostname. This specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encryption, an attacker on this path can also learn the destination server name. A similar attack applies if the client can be linked to a request from the resolver to a DNS authority.

ECH は、TLS が SNI を公開しないことを保証しますが、サーバーのホスト名を解決するために使用される DNS クエリにも同じ情報が存在します。この仕様では、DNS リゾルバーからサーバー名が隠蔽されません。DNS メッセージが認証された暗号化を行わずにクライアントとリゾルバーの間で送信される場合、このパス上の攻撃者は宛先サーバー名を知ることもできます。同様の攻撃は、クライアントがリゾルバーから DNS 機関へのリクエストにリンクされている場合にも適用されます。

An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, even when the client and recursive resolver validate DNSSEC [RFC9364] and use a secure transport. These downgrade attacks can prevent a client from being aware that "ech" is configured, which could result in the client sending the ClientHello in cleartext. To prevent downgrades, Section 3.1 of [SVCB] recommends that clients abandon the connection attempt when such an attack is detected.

SVCB の解決を阻止できる攻撃者は、クライアントに関連するセキュリティ上の利点を一切拒否する可能性があります。敵対的な再帰リゾルバーは常に SVCB クエリへのサービスを拒否できますが、クライアントと再帰リゾルバーが DNSSEC [RFC9364] を検証し、安全なトランスポートを使用している場合でも、ネットワーク仲介者が解決を妨げる場合があります。これらのダウングレード攻撃により、クライアントは「ech」が設定されていることを認識できなくなり、クライアントが ClientHello をクリアテキストで送信する可能性があります。ダウングレードを防ぐために、[SVCB] のセクション 3.1 では、そのような攻撃が検出された場合にクライアントが接続の試みを放棄することを推奨しています。

9. IANA Considerations

9. IANAの考慮事項

IANA has modified the entry for "ech" in the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry group as follows:

IANA は、「DNS Service Bindings (SVCB)」レジストリグループの「DNS SVCB Service Parameter Keys (SvcParamKeys)」レジストリの「ech」のエントリを次のように変更しました。

      +========+======+====================+============+===========+
      | Number | Name | Meaning            | Change     | Reference |
      |        |      |                    | Controller |           |
      +========+======+====================+============+===========+
      | 5      | ech  | TLS Encrypted      | IETF       | RFC 9848  |
      |        |      | ClientHello Config |            |           |
      +--------+------+--------------------+------------+-----------+

                                  Table 1

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

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

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [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>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [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>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/info/rfc9364>.

   [SVCB]     Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/info/rfc9460>.

10.2. Informative References

10.2. 参考引用

   [BCP219]   Best Current Practice 219,
              <https://www.rfc-editor.org/info/bcp219>.
              At the time of writing, this BCP comprises the following:

              Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/info/rfc9499>.

   [CLINIC]   Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
              Why You Went to the Clinic: Risks and Realization of HTTPS
              Traffic Analysis", Lecture Notes in Computer Science, vol.
              8555, pp. 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,
              <https://doi.org/10.1007/978-3-319-08506-7_8>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/info/rfc7838>.

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

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

   [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/info/rfc9147>.

Authors' Addresses

著者の住所

   Ben Schwartz
   Meta Platforms, Inc.
   Email: ietf@bemasc.net

   Mike Bishop
   Akamai Technologies
   Email: mbishop@evequefou.be

   Erik Nygren
   Akamai Technologies
   Email: erik+ietf@nygren.org

RFC 9848 - Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings 日本語訳

Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

DNS サービス バインディングを使用した TLS 暗号化 ClientHello のブートストラップ

Abstract

概要

Status of This Memo

本文書の状態

Copyright Notice

著作権表示

Table of Contents

目次

1. Overview

1. 概要

2. Terminology

2. 用語

3. SvcParam for ECH Configuration

3. ECH 構成用の SvcParam

4. Requirements for Server Deployments

4. サーバー展開の要件

5. Requirements for Client Implementations

5. クライアント実装の要件

5.1. Disabling Fallback

5.1. フォールバックの無効化

5.2. ClientHello Construction

5.2. ClientHello Construction

5.3. Performance Optimizations

5.3. パフォーマンスの最適化

6. Interaction with HTTP Alt-Svc

6. HTTP Alt-Svc との対話

7. Examples

7. 例

8. Security Considerations

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

9. IANA Considerations

9. IANAの考慮事項

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

10.2. Informative References

10.2. 参考引用

Authors' Addresses

著者の住所

DNS サービスバインディングを使用した TLS 暗号化 ClientHello のブートストラップ