Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 9540 Apple Inc.
Category: Standards Track T. Reddy.K
ISSN: 2070-1721 Nokia
February 2024
This document defines a parameter that can be included in Service Binding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an Oblivious Gateway Resource through which to access the target. This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource.
このドキュメントでは、サービスバインディング（SVCB）およびHTTPS DNSリソースレコードに含めることができるパラメーターを定義して、ターゲットにアクセスするための忘却のゲートウェイリソースを提供することにより、忘却のHTTPを使用してサービスにアクセスできることを示します。このドキュメントでは、発見された忘却のゲートウェイリソースの重要な構成を学習するためのメカニズムも定義しています。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9540.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9540で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Applicability
4. The "ohttp" SvcParamKey
4.1. Use in HTTPS Service RRs
4.2. Use in DNS Server SVCB RRs
4.2.1. Use with DDR
4.2.2. Use with DNR
5. Gateway Location
6. Key Configuration Fetching
7. Security and Privacy Considerations
7.1. Key Targeting Attacks
7.2. dohpath Targeting Attacks
8. IANA Considerations
8.1. SVCB Service Parameter
8.2. Well-Known URI
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
Oblivious HTTP [OHTTP] allows clients to encrypt messages exchanged with an Oblivious Target Resource (target). The messages are encapsulated in encrypted messages to an Oblivious Gateway Resource (gateway), which offers Oblivious HTTP access to the target. The gateway is accessed via an Oblivious Relay Resource (relay), which proxies the encapsulated messages to hide the identity of the client. Overall, this architecture is designed in such a way that the relay cannot inspect the contents of messages, and the gateway and target cannot learn the client's identity from a single transaction.
忘れられないHTTP [OHTTP]により、クライアントは、忘却のターゲットリソース（ターゲット）と交換されたメッセージを暗号化できます。メッセージは、暗号化されたメッセージにカプセル化されており、ターゲットへの忘れられないHTTPアクセスを提供する忘れられないゲートウェイリソース（Gateway）です。ゲートウェイには、クライアントのIDを隠すためにカプセル化されたメッセージをプロキシを付けて、気まぐれなリレーリソース（リレー）を介してアクセスされます。全体として、このアーキテクチャは、リレーがメッセージの内容を検査できないように設計されており、ゲートウェイとターゲットは単一のトランザクションからクライアントのIDを学習できません。
Since Oblivious HTTP deployments typically involve very specific coordination between clients, relays, and gateways, the key configuration is often shared in a bespoke fashion. However, some deployments involve clients discovering targets and their associated gateways more dynamically. For example, a network might operate a DNS resolver that provides more optimized or more relevant DNS answers and is accessible using Oblivious HTTP, and might want to advertise support for Oblivious HTTP via mechanisms like Discovery of Designated Resolvers [DDR] and Discovery of Network-designated Resolvers [DNR]. Clients can access these gateways through trusted relays.
忘れられないHTTP展開には通常、クライアント、リレー、およびゲートウェイ間の非常に具体的な調整が含まれるため、主要な構成はオーダーメイドの方法で共有されることがよくあります。ただし、一部の展開では、クライアントがターゲットとそれに関連するゲートウェイをより動的に発見することが含まれます。たとえば、ネットワークは、より最適化されたまたはより関連性の高いDNS回答を提供し、忘れられないHTTPを使用してアクセス可能なDNSリゾルバーを操作する場合があり、指定されたリゾルバーの発見やネットワークの発見などのメカニズムを介して、忘却のHTTPのサポートを宣伝したい場合があります。指定されたリゾルバー[DNR]。クライアントは、信頼できるリレーを介してこれらのゲートウェイにアクセスできます。
This document defines a way to use DNS resource records (RRs) to advertise that an HTTP service supports Oblivious HTTP. This advertisement is a parameter that can be included in Service Binding (SVCB) and HTTPS DNS RRs [SVCB] (Section 4). The presence of this parameter indicates that a service can act as a target and has a gateway that can provide access to the target.
このドキュメントでは、DNSリソースレコード（RRS）を使用して、HTTPサービスが忘却のHTTPをサポートすることを宣伝する方法を定義しています。この広告は、サービスバインディング（SVCB）およびHTTPS DNS RRS [SVCB]（セクション4）に含めることができるパラメーターです。このパラメーターの存在は、サービスがターゲットとして機能し、ターゲットへのアクセスを提供できるゲートウェイがあることを示しています。
The client learns the URI to use for the gateway using a well-known URI suffix [WELLKNOWN], "ohttp-gateway", which is accessed on the target (Section 5). This means that for deployments that support this kind of discovery, the Gateway and Target Resources need to be located on the same host.
クライアントは、ターゲット（セクション5）にアクセスされる、よく知られているURIサフィックス[よく知られている]「OHTTP-Gateway」を使用して、ゲートウェイに使用するURIを学習します。これは、この種の発見をサポートする展開のために、ゲートウェイとターゲットリソースを同じホストに配置する必要があることを意味します。
This document also defines a way to fetch a gateway's key configuration from the gateway (Section 6).
このドキュメントでは、ゲートウェイからゲートウェイのキー構成を取得する方法も定義されています（セクション6）。
This mechanism does not aid in the discovery of relays; relay configuration is out of scope for this document. Models in which this discovery mechanism is applicable are described in Section 3.
このメカニズムは、リレーの発見に役立ちません。このドキュメントのリレー構成は範囲外です。この発見メカニズムが適用されるモデルについては、セクション3に記載されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
There are multiple models in which the discovery mechanism defined in this document can be used. These include:
このドキュメントで定義されている発見メカニズムを使用できる複数のモデルがあります。これらには以下が含まれます：
* Upgrading regular (non-proxied) HTTP to Oblivious HTTP. In this model, the client intends to communicate with a specific target service and prefers to use Oblivious HTTP if it is available. The target service has a gateway that it offers to allow access using Oblivious HTTP. Once the client learns about the gateway, it "upgrades" its requests from non-proxied HTTP to Oblivious HTTP to access the target service.
* 通常の（洗練されていない）httpを忘却のhttpにアップグレードします。このモデルでは、クライアントは特定のターゲットサービスと通信することを意図しており、利用可能な場合は忘れられないHTTPを使用することを好みます。ターゲットサービスには、忘れられないHTTPを使用してアクセスを許可するために提供するゲートウェイがあります。クライアントがゲートウェイについて学習すると、ターゲットサービスにアクセスするために、装飾されていないHTTPから忘れられないHTTPへの要求を「アップグレード」します。
* Discovering alternative Oblivious HTTP services. In this model, the client has a default target service that it uses. For example, this may be a public DNS resolver that is accessible over Oblivious HTTP. The client is willing to use alternative target services if they are discovered, which may provide more optimized or more relevant responses.
* 代替の忘却のHTTPサービスの発見。このモデルでは、クライアントには使用するデフォルトのターゲットサービスがあります。たとえば、これは、忘れられないHTTPでアクセスできるパブリックDNSリゾルバーかもしれません。クライアントは、発見された場合、代替ターゲットサービスを使用する意思があります。
In both of these deployment models, the client is configured with a relay that it trusts for Oblivious HTTP transactions. This relay needs to provide either (1) generic access to gateways or (2) a service to clients to allow them to check which gateways are accessible.
これらの両方の展開モデルでは、クライアントは、忘れられないHTTPトランザクションを信頼するリレーで構成されています。このリレーは、（1）ゲートウェイへの一般的なアクセス、または（2）クライアントへのサービスを提供する必要があります。
The "ohttp" SvcParamKey is used to indicate that a service described in a SVCB RR can be accessed as a target using an associated gateway. The service that is queried by the client hosts one or more Target Resources.
「OHTTP」SVCParamkeyは、SVCB RRで説明されているサービスに関連するゲートウェイを使用してターゲットとしてアクセスできることを示すために使用されます。クライアントが照会するサービスは、1つ以上のターゲットリソースをホストします。
In order to access the service's Target Resources using Oblivious HTTP, the client needs to send encapsulated messages to the Gateway Resource and the gateway's key configuration (both of which can be retrieved using the method described in Section 6).
忘却のHTTPを使用してサービスのターゲットリソースにアクセスするには、クライアントはカプセル化されたメッセージをゲートウェイリソースとゲートウェイのキー構成に送信する必要があります（どちらもセクション6で説明したメソッドを使用して取得できます）。
Both the presentation and wire-format values for the "ohttp" parameter MUST be empty.
「OHTTP」パラメーターのプレゼンテーション値とワイヤー形式値の両方が空でなければなりません。
Services can include the "ohttp" parameter in the mandatory parameter list if the service is only accessible using Oblivious HTTP. Marking the "ohttp" parameter as mandatory will cause clients that do not understand the parameter to ignore that SVCB RR. Including the "ohttp" parameter without marking it mandatory advertises a service that is optionally available using Oblivious HTTP. Note also that multiple SVCB RRs can be provided to indicate separate configurations.
サービスが忘却のHTTPを使用してのみアクセスできる場合、サービスには「OHTTP」パラメーターを必須パラメーターリストに含めることができます。「OHTTP」パラメーターを必須としてマークすると、パラメーターを理解していないクライアントがそのSVCB RRを無視することができます。必須のhttpを使用してオプションで利用可能なサービスをマークすることなく「ohttp」パラメーターを含めます。また、複数のSVCB RRを提供して、個別の構成を示すことができることにも注意してください。
The media type to use for encapsulated requests made to a target service depends on the scheme of the SVCB RR. This document defines the interpretation for the "https" scheme [SVCB] and the "dns" scheme [DNS-SVCB]. Other schemes that want to use this parameter MUST define the interpretation and meaning of the configuration.
ターゲットサービスに行われたカプセル化された要求に使用するメディアタイプは、SVCB RRのスキームに依存します。このドキュメントでは、「HTTPS」スキーム[SVCB]および「DNS」スキーム[DNS-SVCB]の解釈を定義します。このパラメーターを使用したい他のスキームは、構成の解釈と意味を定義する必要があります。
For the "https" scheme, which uses the HTTPS RR type instead of SVCB, the presence of the "ohttp" parameter means that the target being described is an Oblivious HTTP service that is accessible using the default "message/bhttp" media type [OHTTP] [BINARY-HTTP].
SVCBの代わりにHTTPS RRタイプを使用する「HTTPS」スキームの場合、「OHTTP」パラメーターの存在は、説明されているターゲットがデフォルトの「メッセージ/BHTTP」メディアタイプを使用してアクセス可能な忘れられるHTTPサービスであることを意味します。ohttp] [binary-http]。
For example, an HTTPS service RR for svc.example.com that supports Oblivious HTTP could look like this:
たとえば、忘れられないHTTPをサポートするSVC.example.comのHTTPSサービスRRは次のようになります。
svc.example.com. 7200 IN HTTPS 1 . ( alpn=h2 ohttp )
A similar RR for a service that only supports Oblivious HTTP could look like this:
気まぐれなHTTPのみをサポートするサービスの同様のRRは、次のようになります。
svc.example.com. 7200 IN HTTPS 1 . ( mandatory=ohttp ohttp )
For the "dns" scheme, as defined in [DNS-SVCB], the presence of the "ohttp" parameter means that the DNS server being described has a DNS-over-HTTPS (DoH) service [DOH] that can be accessed using Oblivious HTTP. Requests to the resolver are sent to the gateway using binary HTTP with the default "message/bhttp" media type [BINARY-HTTP], containing inner requests that use the "application/ dns-message" media type [DOH].
[dns-svcb]で定義されている「dns」スキームの場合、「ohttp」パラメーターの存在は、記載されているDNSサーバーにDNS-over-https（doh）サービス[DOH]を使用してアクセスできることを意味します。忘れられないhttp。リゾルバーへのリクエストは、「アプリケーション/ DNSメサージ」メディアタイプ[DOH]を使用する内部リクエストを含む、デフォルトの「メッセージ/ BHTTP」メディアタイプ[Binary-HTTP]を使用してバイナリHTTPを使用してゲートウェイに送信されます。
If the "ohttp" parameter is included in a DNS server SVCB RR, the "alpn" parameter MUST include at least one HTTP value (such as "h2" or "h3").
「OHTTP」パラメーターがDNSサーバーSVCB RRに含まれている場合、「ALPN」パラメーターには、少なくとも1つのHTTP値（「H2」または「H3」など）を含める必要があります。
In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, their associated gateways need to be accessible via a client-trusted relay. DoH recursive resolvers used with the discovery mechanisms described in this section can be either publicly accessible or specific to a network. In general, only publicly accessible DoH recursive resolvers will work as Oblivious HTTP targets, unless there is a coordinated deployment with a relay to access the network-specific DoH recursive resolvers.
DOH対応の再帰的リゾルバーが忘れられないHTTPターゲットとして機能するためには、それらに関連するゲートウェイにクライアントに信頼されたリレーを介してアクセスできる必要があります。このセクションで説明したディスカバリーメカニズムで使用されるDOH再帰リゾルバーは、ネットワークに公開されているか、固有のものです。一般に、ネットワーク固有のDOH再帰リゾルバーにアクセスするためのリレーを使用した調整された展開がない限り、公開されているDOH再帰リゾルバーのみが忘却のHTTPターゲットとして機能します。
Clients can discover that a DoH recursive resolver supports Oblivious HTTP using DDR, by either querying _dns.resolver.arpa to a locally configured resolver or querying using the name of a resolver [DDR].
クライアントは、DOHの再帰リゾルバーが、_dns.resolver.arpaをローカルで構成されたリゾルバーに照会するか、リゾルバー[DDR]の名前を使用して照会することにより、DDRを使用した忘却のHTTPをサポートすることを発見できます。
For example, a DoH service advertised over DDR can be annotated as supporting resolution via Oblivious HTTP using the following RR:
たとえば、DDRを介して宣伝されているDOHサービスは、次のRRを使用して、忘却のHTTPを介して解像度をサポートするものとして注釈を付けることができます。
_dns.resolver.arpa 7200 IN SVCB 1 doh.example.net (
alpn=h2 dohpath=/dns-query{?dns} ohttp )
Clients still need to perform verification of oblivious DoH servers -- specifically, the TLS certificate checks described in Section 4.2 of [DDR]. Since the Gateway and Target Resources for discovered oblivious services need to be on the same host, this means that the client needs to verify that the certificate presented by the gateway passes the required checks. These checks can be performed when looking up the configuration on the gateway as described in Section 6 and can be done either directly or via the relay or another proxy to avoid exposing client IP addresses.
クライアントは、[DDR]のセクション4.2で説明されているTLS証明書チェック、特に[DDR]のセクションで説明されているTLS証明書チェックの検証を実行する必要があります。発見された忘却サービスのゲートウェイとターゲットのリソースは同じホストにある必要があるため、これはクライアントがゲートウェイによって提示された証明書が必要なチェックを通過することを確認する必要があることを意味します。これらのチェックは、セクション6で説明されているようにゲートウェイの構成を検索するときに実行でき、クライアントIPアドレスの公開を避けるために、直接またはリレーまたは別のプロキシを介して実行できます。
Opportunistic Discovery [DDR], where only the IP address is validated, SHOULD NOT be used in general with Oblivious HTTP, since this mode primarily exists to support resolvers that use private or local IP addresses, which will usually not be accessible when using a relay. If a configuration occurs where the resolver is accessible but cannot use certificate-based validation, the client MUST ensure that the relay only accesses the gateway and target using the unencrypted resolver's original IP address.
IPアドレスのみが検証されている日和見的発見[DDR]は、主にプライベートまたはローカルのIPアドレスを使用するリゾルバーをサポートするために主に存在するため、忘却のHTTPで一般的に使用すべきではありません。。リゾルバーがアクセス可能であるが証明書ベースの検証を使用できない場合に構成が発生した場合、クライアントは、リレーが暗号化されていないリゾルバーの元のIPアドレスを使用してゲートウェイとターゲットにのみアクセスすることを確認する必要があります。
For the case of DoH recursive resolvers, clients also need to ensure that they are not being targeted with unique DoH paths that would reveal their identity. See Section 7 for more discussion.
DOHの再帰的リソースバーの場合、クライアントは、自分のアイデンティティを明らかにする独自のDOHパスで標的にされていないことを確認する必要があります。詳細については、セクション7を参照してください。
The SvcParamKey defined in this document also can be used with Discovery of Network-designated Resolvers [DNR]. In this case, the oblivious configuration and path parameters can be included in DHCP and Router Advertisement messages.
このドキュメントで定義されているSVCParamkeyは、ネットワーク指定リゾルバー[DNR]の発見とともに使用することもできます。この場合、DHCPおよびルーター広告メッセージに忘れられない構成とパスパラメーターを含めることができます。
While DNR does not require the same kind of verification as DDR, clients that learn about DoH recursive resolvers still need to ensure that they are not being targeted with unique DoH paths that would reveal their identity. See Section 7 for more discussion.
DNRはDDRと同じ種類の検証を必要としませんが、DOHの再帰リゾルバーについて学ぶクライアントは、アイデンティティを明らかにする独自のDOHパスで標的にされていないことを確認する必要があります。 詳細については、セクション7を参照してください。
Once a client has discovered that a service supports Oblivious HTTP via the "ohttp" parameter in a SVCB or HTTPS RR, it needs to be able to send requests via a relay to the correct gateway location.
クライアントが、SVCBまたはHTTPS RRの「OHTTP」パラメーターを介してサービスが忘れられないHTTPをサポートすることをクライアントが発見したら、リレーを介して正しいゲートウェイの位置にリクエストを送信できる必要があります。
This document defines a well-known resource [WELLKNOWN], "/.well-known/ohttp-gateway", which is an Oblivious Gateway Resource available on the same host as the Target Resource.
このドキュメントでは、よく知られているリソース[よく知られている]、「/.Well-Known/OHTTP-Gateway」を定義します。
Some servers might not want to operate the gateway on a well-known URI. In such cases, these servers can use 3xx (Redirection) responses (Section 15.4 of [HTTP]) to direct clients and relays to the correct location of the gateway. Such redirects would apply to both (1) requests made to fetch key configurations (as defined in Section 6) and (2) encapsulated requests made via a relay.
一部のサーバーは、よく知られているURIでゲートウェイを操作したくない場合があります。このような場合、これらのサーバーは3xx（リダイレクト）応答（[http]のセクション15.4）を使用して、クライアントを指示し、ゲートウェイの正しい場所にリレーできます。このようなリダイレクトは、キー構成（セクション6で定義されている）と（2）リレーを介して行われたカプセル化されたリクエストを取得するために行われた（1）リクエストの両方に適用されます。
If a client receives a redirect when fetching the key configuration from the well-known Gateway Resource, it MUST NOT communicate the redirected gateway URI to the relay as the location of the gateway to use. Doing so would allow the gateway to target clients by encoding unique or client-identifying values in the redirected URI. Instead, relays being used with dynamically discovered gateways MUST use the well-known Gateway Resource and follow any redirects independently of redirects that clients received. The relay can remember such redirects across oblivious requests for all clients in order to avoid added latency.
よく知られているゲートウェイリソースからキー構成を取得するときにクライアントがリダイレクトを受信した場合、使用するゲートウェイの位置として、リダイレクトされたゲートウェイURIをリレーに通知してはなりません。そうすることで、リダイレクトされたURIの一意またはクライアントを特定する値をエンコードすることにより、ゲートウェイがクライアントをターゲットにすることができます。代わりに、動的に発見されたゲートウェイで使用されるリレーは、よく知られているゲートウェイリソースを使用し、クライアントが受け取ったリダイレクトとは無関係にリダイレクトに従う必要があります。リレーは、追加のレイテンシを避けるために、すべてのクライアントの不当な要求を介したそのようなリダイレクトを覚えています。
Clients also need to know the key configuration of a gateway before encapsulating and sending requests to the relay.
また、クライアントはリレーにリクエストをカプセル化して送信する前に、ゲートウェイの重要な構成を知る必要があります。
If a client fetches the key configuration directly from the gateway, it will expose identifiers like a client IP address to the gateway. The privacy and security implications of fetching the key configuration are discussed more in Section 7. Clients can use an HTTP proxy to hide their IP addresses when fetching key configurations. Clients can also perform consistency checks to validate that they are not receiving unique key configurations, as discussed in Section 7.1.
クライアントがキー構成をゲートウェイから直接取得すると、クライアントIPアドレスなどの識別子がゲートウェイに公開されます。キー構成を取得することのプライバシーとセキュリティの意味について、セクション7で詳細について説明します。クライアントは、キー構成を取得するときにHTTPプロキシを使用してIPアドレスを非表示にできます。セクション7.1で説明したように、クライアントは一貫性チェックを実行して、一意のキー構成を受信していないことを検証することもできます。
In order to fetch the key configuration of a gateway discovered in the manner described in Section 5, the client issues a GET request (either through a proxy or directly) to the URI of the gateway specifying the "application/ohttp-keys" media type [OHTTP] in the Accept header.
セクション5で説明されている方法で発見されたゲートウェイのキー構成を取得するために、クライアントは「アプリケーション/Ohttp-Keys」メディアタイプを指定するゲートウェイのURIに（プロキシまたは直接）get requestを発行します。[OHTTP] acceptヘッダー。
For example, if the client knows an Oblivious Gateway URI, https://svc.example.com/.well-known/ohttp-gateway, it could fetch the key configuration with the following request:
たとえば、クライアントが忘れられないゲートウェイURI、https://svc.example.com/.well-nown/ohttp-gatewayを知っている場合、次の要求でキー構成を取得できます。
GET /.well-known/ohttp-gateway HTTP/1.1
Host: svc.example.com
Accept: application/ohttp-keys
Gateways that coordinate with targets that advertise Oblivious HTTP support SHOULD support GET requests for their key configuration in this manner, unless there is another out-of-band configuration model that is usable by clients. Gateways respond with their key configuration in the response body, with a content type of "application/ohttp-keys".
クライアントが使用できる別の帯域外構成モデルがない限り、忘れられないHTTPサポートを宣伝するターゲットと調整するゲートウェイは、この方法でキー構成の取得要求をサポートする必要があります。ゲートウェイは、コンテンツタイプの「アプリケーション/OHTTP-KEY」で、応答本体のキー構成で応答します。
Attackers on a network can remove SVCB information from cleartext DNS answers that are not protected by DNSSEC [DNSSEC]. This can effectively downgrade clients. However, since SVCB indications for Oblivious HTTP support are just hints, a client can mitigate this by always checking for a gateway configuration (Section 6) on the well-known gateway location (Section 5). Using encrypted DNS along with DNSSEC can also provide such a mitigation.
ネットワーク上の攻撃者は、DNSSEC [DNSSEC]によって保護されていないClearText DNS回答からSVCB情報を削除できます。これにより、クライアントを効果的にダウングレードできます。ただし、忘れられないHTTPサポートのSVCB適応症は単なるヒントであるため、クライアントは、よく知られているゲートウェイの場所（セクション5）で常にゲートウェイ構成（セクション6）をチェックすることでこれを軽減できます。暗号化されたDNSとDNSSECを使用すると、このような緩和も提供できます。
When clients fetch a gateway's configuration (Section 6), they can expose their identity in the form of an IP address if they do not connect via a proxy or some other IP-hiding mechanism. In some circumstances, this might not be a privacy concern, since revealing that a particular client IP address is preparing to use an Oblivious HTTP service can be expected. However, if a client is otherwise trying to hide its IP address or location (and not merely decouple its specific requests from its IP address), or if revealing its IP address facilitates key targeting attacks (if a gateway service uses IP addresses to associate specific configurations with specific clients), a proxy or similar mechanism can be used to fetch the gateway's configuration.
クライアントがゲートウェイの構成（セクション6）を取得すると、プロキシまたは他のIPハイディングメカニズムを介して接続しない場合、IPアドレスの形でアイデンティティを公開できます。状況によっては、特定のクライアントIPアドレスが忘れられないHTTPサービスを使用する準備をしていることを明らかにするため、これはプライバシーの懸念ではないかもしれません。ただし、クライアントがIPアドレスまたは場所を非表示にしようとしている場合（単に特定のリクエストをIPアドレスから切り離すだけではありません）、またはIPアドレスを表示するとキーターゲティング攻撃が容易になります（ゲートウェイサービスがIPアドレスを使用して特定の関連付けを行う場合特定のクライアントを使用した構成）、プロキシまたは同様のメカニズムを使用して、ゲートウェイの構成を取得できます。
When discovering designated oblivious DoH recursive resolvers using this mechanism, clients need to ensure that the designation is trusted in lieu of being able to directly check the contents of the gateway server's TLS certificate. See Section 4.2.1 for more discussion, as well as Section 8 ("Security Considerations") of [DNS-SVCB].
このメカニズムを使用して指定されたDOHの再帰的リゾルバーを発見する場合、クライアントは、Gateway ServerのTLS証明書の内容を直接チェックできるという代わりに、指定が信頼されていることを確認する必要があります。詳細については、[DNS-SVCB]のセクション8（「セキュリティ上の考慮事項」）については、セクション4.2.1を参照してください。
As discussed in [OHTTP], client requests using Oblivious HTTP can only be linked by recognizing the key configuration. In order to prevent unwanted linkability and tracking, clients using any key configuration discovery mechanism need to be concerned with attacks that target a specific user or population with a unique key configuration.
[OHTTP]で説明したように、クライアントのリクエストは、忘却のHTTPを使用して、キー構成を認識することによってのみリンクできます。不要なリンク可能性と追跡を防ぐために、キー構成ディスカバリーメカニズムを使用するクライアントは、一意のキー構成で特定のユーザーまたは母集団をターゲットにする攻撃に関係する必要があります。
There are several approaches clients can use to mitigate key targeting attacks. [CONSISTENCY] provides an overview of the options for ensuring that the key configurations are consistent between different clients. Clients SHOULD employ some technique to mitigate key targeting attacks, such as the option of confirming the key with a shared proxy as described in [CONSISTENCY]. If a client detects that a gateway is using per-client targeted key configuration, the client can stop using the gateway and, potentially, report the targeting attack so that other clients can avoid using this gateway in the future.
クライアントが主要なターゲティング攻撃を緩和するために使用できるアプローチがいくつかあります。[一貫性]は、異なるクライアント間で重要な構成が一貫していることを保証するためのオプションの概要を提供します。クライアントは、[一貫性]で説明されているように、キーを共有プロキシで確認するオプションなど、キーターゲティング攻撃を緩和するための手法を使用する必要があります。クライアントがゲートウェイがクライアントごとのターゲットを使用しているキー構成を使用していることを検出した場合、クライアントはゲートウェイの使用を停止し、潜在的に、他のクライアントが将来このゲートウェイの使用を避けることができるようにターゲティング攻撃を報告できます。
For oblivious DoH servers, an attacker could use unique "dohpath" values to target or identify specific clients. This attack is very similar to the generic OHTTP key targeting attack described above.
気付かないDOHサーバーの場合、攻撃者は一意の「Dohpath」値を使用して、特定のクライアントをターゲットまたは識別することができます。この攻撃は、上記の一般的なOHTTPキーターゲティング攻撃に非常に似ています。
A client can avoid these targeting attacks by only allowing a single "dohpath" value, such as the commonly used "/dns-query{?dns}" or another pre-known value. If the client allows arbitrary "dohpath" values, it SHOULD mitigate targeting attacks with a consistency check, such as using one of the mechanisms described in [CONSISTENCY] to validate the "dohpath" value with another source. Clients might choose to only employ a consistency check on a percentage of discovery events, depending on the capacity of consistency check options and their deployment threat model.
クライアントは、一般的に使用される「/dns-query {？dns}」などの単一の「dohpath」値のみを許可することで、これらのターゲティング攻撃を回避できます。クライアントが任意の「dohpath」値を許可する場合、[一貫性]で説明されているメカニズムのいずれかを使用して別のソースと「Dohpath」値を検証するなど、一貫性チェックでターゲティング攻撃を緩和する必要があります。クライアントは、一貫性チェックオプションの容量と展開脅威モデルの能力に応じて、発見イベントの割合でのみ一貫性チェックを使用することを選択できます。
This document adds the following entry to the "Service Parameter Keys (SvcParamKeys)" registry [SVCB]. This parameter is defined in Section 4.
このドキュメントでは、次のエントリを「Service Parameter Keys（SVCParamkeys）」レジストリ[SVCB]に追加します。このパラメーターは、セクション4で定義されています。
+========+=======+=======================+============+===========+
| Number | Name | Meaning | Change | Reference |
| | | | Controller | |
+========+=======+=======================+============+===========+
| 8 | ohttp | Denotes that a | IETF | RFC 9540, |
| | | service operates an | | Section 4 |
| | | Oblivious HTTP target | | |
+--------+-------+-----------------------+------------+-----------+
Table 1
IANA has added one entry in the "Well-Known URIs" registry [WELLKNOWN].
IANAは、「有名なURIS」レジストリ[よく知られている]に1つのエントリを追加しました。
URI Suffix:
URIサフィックス：
ohttp-gateway
ohttp-gateway
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9540
RFC 9540
Status:
状態：
permanent
永続パーマネント恒久常任不変永住永久的な一定不変
Related Information:
関連情報：
N/A
n/a
[BINARY-HTTP]
Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
<https://www.rfc-editor.org/info/rfc9292>.
[DDR] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/info/rfc9462>.
[DNR] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
[DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers",
RFC 9461, DOI 10.17487/RFC9461, November 2023,
<https://www.rfc-editor.org/info/rfc9461>.
[DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/info/rfc9458>.
[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>.
[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>.
[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>.
[WELLKNOWN]
Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-01,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-01>.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
Tommy Pauly
Apple Inc.
Email: tpauly@apple.com
Tirumaleswar Reddy.K
Nokia
Email: kondtir@gmail.com