[要約] RFC 8882は、DNS-SDのプライバシーとセキュリティ要件に関する標準です。このRFCの目的は、DNS-SDの実装におけるプライバシーとセキュリティの保護を強化することです。DNS-SDを使用する際には、このRFCの要件を遵守することが重要です。
Internet Engineering Task Force (IETF) C. Huitema
Request for Comments: 8882 Private Octopus Inc.
Category: Informational D. Kaiser
ISSN: 2070-1721 University of Luxembourg
September 2020
DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements
DNSベースのサービス発見（DNS-SD）プライバシーとセキュリティ要件
Abstract
概要
DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service.
DNS-SD（DNSベースのサービス発見）は通常、サービスを提供して要求するデバイスに関する情報を開示しています。この情報には、ホスト名、ネットワークパラメータ、およびおそらく対応するサービスインスタンスのさらなる説明が含まれます。特に、モバイル機器が公衆ホットスポットでDNSベースのサービス発見に従事している場合、深刻なプライバシー問題が発生します。プライバシー尊重発見サービスの要件を分析します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8882.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8882で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Threat Model
3. Threat Analysis
3.1. Service Discovery Scenarios
3.1.1. Private Client and Public Server
3.1.2. Private Client and Private Server
3.1.3. Wearable Client and Server
3.2. DNS-SD Privacy Considerations
3.2.1. Information Made Available Via DNS-SD Resource Records
3.2.2. Privacy Implication of Publishing Service Instance
Names
3.2.3. Privacy Implication of Publishing Node Names
3.2.4. Privacy Implication of Publishing Service Attributes
3.2.5. Device Fingerprinting
3.2.6. Privacy Implication of Discovering Services
3.3. Security Considerations
3.3.1. Authenticity, Integrity, and Freshness
3.3.2. Confidentiality
3.3.3. Resistance to Dictionary Attacks
3.3.4. Resistance to Denial-of-Service Attacks
3.3.5. Resistance to Sender Impersonation
3.3.6. Sender Deniability
3.4. Operational Considerations
3.4.1. Power Management
3.4.2. Protocol Efficiency
3.4.3. Secure Initialization and Trust Models
3.4.4. External Dependencies
4. Requirements for a DNS-SD Privacy Extension
4.1. Private Client Requirements
4.2. Private Server Requirements
4.3. Security and Operation
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
DNS-Based Service Discovery (DNS-SD) [RFC6763] over Multicast DNS (mDNS) [RFC6762] enables zero-configuration service discovery in local networks. It is very convenient for users, but it requires the public exposure of the offering and requesting identities along with information about the offered and requested services. Parts of the published information can seriously breach the user's privacy. These privacy issues and potential solutions are discussed in [KW14a], [KW14b], and [K17]. While the multicast nature of mDNS makes these risks obvious, most risks derive from the observability of transactions. These risks also need to be mitigated when using server-based variants of DNS-SD.
DNSベースのサービス検出（DNS-SD）[RFC6763] OVER MULTICAST DNS（MDNS）[RFC6762]は、ローカルネットワークで設定ゼロコンフィギュレーションサービス検出を可能にします。それはユーザーにとって非常に便利ですが、提供されたサービスと要求されたサービスに関する情報とともに、オファリングの公的にわたる、身元を要求する必要があります。公開された情報の一部は、ユーザーのプライバシーを真剣に違反することができます。これらのプライバシーの問題と潜在的な解決策は[KW14A]、[KW14B]、[K17]で説明しています。MDNのマルチキャストの性質はこれらのリスクを明らかにしていますが、ほとんどのリスクは取引の観察可能性に由来します。これらのリスクは、DNS-SDのサーバーベースの変形例を使用する場合も軽減される必要があります。
There are cases when nodes connected to a network want to provide or consume services without exposing their identities to the other parties connected to the same network. Consider, for example, a traveler wanting to upload pictures from a phone to a laptop when both are connected to the Wi-Fi network of an Internet cafe, or two travelers who want to share files between their laptops when waiting for their plane in an airport lounge.
ネットワークに接続されたノードが、同じネットワークに接続されている他の当事者にその身元を露出させることなくサービスを提供または消費したい場合があります。例えば、両方がインターネットカフェのWi-Fiネットワークに接続されているときに電話からノートパソコンに写真をアップロードしたい旅行者、または自分の飛行機を待っているときに自分のラップトップ間でファイルを共有したい2人の旅行者に、空港ラウンジ。
We expect that these exchanges will start with a discovery procedure using DNS-SD over mDNS. One of the devices will publish the availability of a service, such as a picture library or a file store in our examples. The user of the other device will discover this service and then connect to it.
これらの交換は、MDN上のDNS-SDを使用してディスカバリー手順から始まります。いずれかのデバイスは、例の画像ライブラリやファイルストアなどのサービスの可用性を公開します。他のデバイスのユーザーはこのサービスを検出してから接続します。
When analyzing these scenarios in Section 3.1, we find that the DNS-SD messages leak identifying information, such as the Service Instance Name, the hostname, or service properties. We use the following definitions:
セクション3.1でこれらのシナリオを分析するとき、DNS-SDメッセージは、サービスインスタンス名、ホスト名、またはサービスのプロパティなど、情報を識別することを確認します。以下の定義を使用します。
Identity In this document, the term "identity" refers to the identity of the entity (legal person) operating a device.
この文書のアイデンティティ「アイデンティティ」という用語は、デバイスを操作するエンティティ（法人）の身元を指します。
Disclosing an Identity In this document, "disclosing an identity" means showing the identity of operating entities to devices external to the discovery process, e.g., devices on the same network link that are listening to the network traffic but are not actually involved in the discovery process. This document focuses on identity disclosure by data conveyed via messages on the service discovery protocol layer. Still, identity leaks on deeper layers, e.g., the IP layer, are mentioned.
この文書では、「アイデンティティを開示」を「開示する」とは、発見プロセスの外部の装置、例えばネットワークトラフィックを聴いているが実際には発見に関わっていない装置への装置への業務エンティティの身元を示すことを意味する。処理する。この文書は、サービス発見プロトコル層上のメッセージを介して伝達されたデータによるアイデンティティ開示に焦点を当てています。それでも、識別情報がより深い層、例えばIP層に漏れる。
Disclosing Information In this document, "disclosing information" is also focused on disclosure of data conveyed via messages on the service discovery protocol layer, including both identity-revealing information and other still potentially sensitive data.
この文書に「開示情報」は、サービス発見プロトコル層上のメッセージを経由したデータの開示に焦点を当てており、その他の潜在的に潜在的に潜在的に敏感なデータの両方を含む。
This document considers the following attacker types sorted by increasing power. All these attackers can either be passive (they just listen to network traffic they have access to) or active (they additionally can craft and send malicious packets).
この資料は、電力を増やすことによって、次の攻撃者タイプを並べ替えます。これらの攻撃者はすべて受動的であることができます（彼らはただ彼らがアクセスできるネットワークトラフィックを聴く）、またはアクティブな（彼らは追加的に悪意のあるパケットを作成して送ることができる）。
external An external attacker is not on the same network link as victim devices engaging in service discovery; thus, the external attacker is in a different multicast domain.
外部外部攻撃者は、サービス発見に従事する被害者装置と同じネットワークリンク上にありません。したがって、外部攻撃者は異なるマルチキャストドメインにあります。
on-link An on-link attacker is on the same network link as victim devices engaging in service discovery; thus, the on-link attacker is in the same multicast domain. This attacker can also mount all attacks an external attacker can mount.
オンリンクオンリンク攻撃者は、サービス発見に従事する被害者デバイスと同じネットワークリンク上にあります。したがって、オンリンク攻撃者は同じマルチキャストドメインにあります。この攻撃者は、外部の攻撃者がマウントできるすべての攻撃をマウントすることもできます。
MITM A Man-in-the-Middle (MITM) attacker either controls (parts of) a network link or can trick two parties to send traffic via the attacker; thus, the MITM attacker has access to unicast traffic between devices engaging in service discovery. This attacker can also mount all attacks an on-link attacker can mount.
MITM MAN-IN-THE-THE-MIDSTASTIONTERをコントロール（の一部）ネットワークリンクまたは攻撃者を介してトラフィックを送信するための2つの当事者をトリックすることができます。したがって、MITMの攻撃者は、サービス発見に従事する機器間のユニキャストトラフィックにアクセスできます。この攻撃者は、オンリンク攻撃者がマウントできるすべての攻撃をマウントすることもできます。
In this section, we analyze how the attackers described in the previous section might threaten the privacy of entities operating devices engaging in service discovery. We focus on attacks leveraging data transmitted in service discovery protocol messages.
このセクションでは、前のセクションで説明した攻撃者がサービス発見に従事するエンティティのプライバシーを脅かす可能性があるかを分析します。私たちは、サービス発見プロトコルメッセージで送信されたデータを活用する攻撃に焦点を当てています。
In this section, we review common service discovery scenarios and discuss privacy threats and their privacy requirements. In all three of these common scenarios, the attacker is of the type passive on-link.
このセクションでは、一般的なサービス発見シナリオを見直し、プライバシーの脅威とそのプライバシー要件について説明します。これら3つの一般的なシナリオすべてで、攻撃者は型パッシブオンリンクのものです。
Perhaps the simplest private discovery scenario involves a single client connecting to a public server through a public network. A common example would be a traveler using a publicly available printer in a business center, in a hotel, or at an airport.
おそらく最も単純なプライベートディスカバリーシナリオは、公衆ネットワークを介してパブリックサーバーに接続する単一のクライアントが含まれています。一般的な例は、ビジネスセンター、ホテル内、または空港で公的に利用可能なプリンタを使用する旅行者です。
( Taking notes:
( David is printing
( a document.
~~~~~~~~~~~
o
___ o ___
/ \ _|___|_
| | client server |* *|
\_/ __ \_/
| / / Discovery +----------+ |
/|\ /_/ <-----------> | +----+ | /|\
/ | \__/ +--| |--+ / | \
/ | |____/ / | \
/ | / | \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
David Adversary
David敵対者
In that scenario, the server is public and wants to be discovered, but the client is private. The adversary will be listening to the network traffic, trying to identify the visitors' devices and their activity. Identifying devices leads to identifying people, either for surveillance of these individuals in the physical world or as a preliminary step for a targeted cyber attack.
そのシナリオでは、サーバーはパブリックされて発見されたいが、クライアントは非公開です。敵対者は、訪問者のデバイスとその活動を特定しようとしている、ネットワークトラフィックを聴いています。デバイスの識別は、物理的世界のこれらの個人の監視のために、または標的なサイバー攻撃のための予備的なステップとして、人々を識別することにつながります。
The requirement in that scenario is that the discovery activity should not disclose the identity of the client.
そのシナリオの要件は、発見活動がクライアントの身元を開示してはいけないことです。
The second private discovery scenario involves a private client connecting to a private server. A common example would be two people engaging in a collaborative application in a public place, such as an airport's lounge.
2番目のプライベートディスカバリーシナリオは、プライベートサーバーに接続するプライベートクライアントを含みます。一般的な例は、空港のラウンジなど、公共の場所で共同アプリケーションに従事する2人の人々です。
( Taking notes:
( David is meeting
( with Stuart.
~~~~~~~~~~~
o
___ ___ o ___
/ \ / \ _|___|_
| | server client | | |* *|
\_/ __ __ \_/ \_/
| / / Discovery \ \ | |
/|\ /_/ <-----------> \_\ /|\ /|\
/ | \__/ \__/ | \ / | \
/ | | \ / | \
/ | | \ / | \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
David Stuart Adversary
David Stuart Dangersary
In that scenario, the collaborative application on one of the devices will act as a server, and the application on the other device will act as a client. The server wants to be discovered by the client but has no desire to be discovered by anyone else. The adversary will be listening to network traffic, attempting to discover the identity of devices as in the first scenario and also attempting to discover the patterns of traffic, as these patterns reveal the business and social interactions between the owners of the devices.
そのシナリオでは、いずれかのデバイス上の共同アプリケーションがサーバーとして機能し、他のデバイス上のアプリケーションはクライアントとして機能します。サーバーはクライアントによって発見されたいが、他の誰かによって発見されたいという願望はありません。敵対者はネットワークトラフィックを聴いており、最初のシナリオのようにデバイスの身元を発見しようとし、これらのパターンはデバイスの所有者間のビジネスと社会的な相互作用を明らかにするため、トラフィックのパターンを発見しようとしています。
The requirement in that scenario is that the discovery activity should not disclose the identity of either the client or the server nor reveal the business and social interactions between the owners of the devices.
そのシナリオの要件は、発見活動がクライアントまたはサーバーのいずれかのIDを開示したり、デバイスの所有者間のビジネスと社会的な相互作用を明らかにしたりすることです。
The third private discovery scenario involves wearable devices. A typical example would be the watch on someone's wrist connecting to the phone in their pocket.
3番目のプライベートディスカバリーシナリオはウェアラブルデバイスを含みます。典型的な例は、自分のポケットの中の電話に接続する人の手首の時計です。
( Taking notes:
( David is here. His watch is
( talking to his phone.
~~~~~~~~~~~
o
___ o ___
/ \ _|___|_
| | client |* *|
\_/ \_/
| _/ |
/|\ // /|\
/ | \__/ ^ / | \
/ |__ | Discovery / | \
/ |\ \ v / | \
/ \\_\ / \
/ \ server / \
/ \ / \
/ \ / \
/ \ / \
David Adversary
David敵対者
This third scenario is in many ways similar to the second scenario. It involves two devices, one acting as server and the other acting as client, and it leads to the same requirement of the discovery traffic not disclosing the identity of either the client or the server. The main difference is that the devices are managed by a single owner, which can lead to different methods for establishing secure relations between the devices. There is also an added emphasis on hiding the type of devices that the person wears.
この3番目のシナリオは、2番目のシナリオと同様の方法でさまざまです。それは2つのデバイスを含み、1つはサーバーとして機能し、他方がクライアントとして機能し、それはクライアントまたはサーバーのいずれかのアイデンティティを開示していないという発見トラフィックの同じ要件をもたらします。主な違いは、デバイスが単一の所有者によって管理されることであり、それはデバイス間の安全な関係を確立するためのさまざまな方法につながる可能性があります。人が着るデバイスの種類を隠すことにも追加されました。
In addition to tracking the identity of the owner of the devices, the adversary is interested in the characteristics of the devices, such as type, brand, and model. Identifying the type of device can lead to further attacks, from theft to device-specific hacking. The combination of devices worn by the same person will also provide a "fingerprint" of the person, risking identification.
デバイスの所有者のアイデンティティを追跡することに加えて、敵対者はタイプ、ブランド、モデルなどの機器の特性に興味があります。デバイスの種類を識別することは、盗難から装置固有のハッキングへのさらなる攻撃をもたらす可能性がある。同じ人が着用する機器の組み合わせも、その人の「指紋」を提供し、識別をリスクします。
This scenario also represents the general case of bringing private Internet-of-Things (IoT) devices into public places. A wearable IoT device might act as a DNS-SD/mDNS client, which allows attackers to infer information about devices' owners. While the attacker might be a person, as in the example figure, this could also be abused for large-scale data collection installing stationary IoT-device-tracking servers in frequented public places.
このシナリオはまた、プライベートインターネット（IoT）デバイスを公共の場所にする一般的なケースを表しています。ウェアラブルIOTデバイスは、DNS-SD / MDNSクライアントとして機能する可能性があります。これにより、攻撃者はデバイスの所有者に関する情報を推測できます。攻撃者が人物になるかもしれませんが、例の図のように、これは頻繁なIOTデバイス追跡サーバーを頻繁に公共の場所にインストールする大規模データ収集にも乱用する可能性があります。
The issues described in Section 3.1.1, such as identifying people or using the information for targeted attacks, apply here too.
人々の識別やターゲット攻撃のための情報を使用するなどのセクション3.1.1で説明されている問題もここに適用されます。
While the discovery process illustrated in the scenarios in Section 3.1 most likely would be based on [RFC6762] as a means for making service information available, this document considers all kinds of means for making DNS-SD resource records available. These means comprise of but are not limited to mDNS [RFC6762], DNS servers ([RFC1033], [RFC1034], and [RFC1035]), the use of Service Registration Protocol (SRP) [SRP], and multi-link [RFC7558] networks.
3.1節のシナリオに示されているディスカバリープロセスは、サービス情報を利用可能にするための手段として[RFC6762]に基づいている可能性が最も高いですが、この文書はDNS-SDリソースレコードを利用可能にするためのあらゆる種類の手段を考慮します。これらの手段は、MDNS [RFC6762]、DNSサーバ（[RFC1033]、[RFC1034]、[RFC1035]）、サービス登録プロトコル（SRP）[SRP]、マルチリンク[RFC7558]の使用を備えています。]ネットワーク
The discovery scenarios in Section 3.1 illustrate three separate abstract privacy requirements that vary based on the use case. These are not limited to mDNS.
セクション3.1の発見シナリオは、ユースケースに基づいて変わる3つの別々の抽象プライバシー要件を示しています。これらはMDNSに限定されない。
1. Client identity privacy: Client identities are not leaked during service discovery or use.
1. クライアントアイデンティティプライバシー：クライアントアイデンティティは、サービスの検出または使用中にリークされません。
2. Multi-entity, mutual client and server identity privacy: Neither client nor server identities are leaked during service discovery or use.
2. マルチエンティティ、相互クライアントおよびサーバーのIDのプライバシー：サービスの発見中または使用中にクライアントもサーバーのアイデンティティも漏洩しません。
3. Single-entity, mutual client and server identity privacy: Identities of clients and servers owned and managed by the same legal person are not leaked during service discovery or use.
3. 単一エンティティ、相互クライアント、およびサーバーのIDのプライバシー：同一の法人によって所有および管理されているクライアントやサーバーのIDは、サービスの発見または使用中に漏洩しません。
In this section, we describe aspects of DNS-SD that make these requirements difficult to achieve in practice. While it is intended to be thorough, it is not possible to be exhaustive.
このセクションでは、これらの要件を実際に達成するのが困難なDNS-SDの側面について説明します。徹底的になることを意図しているが、網羅的なものであることは不可能です。
Client identity privacy, if not addressed properly, can be thwarted by a passive attacker (see Section 2). The type of passive attacker necessary depends on the means of making service information available. Information conveyed via multicast messages can be obtained by an on-link attacker. Unicast messages are harder to access, but if the transmission is not encrypted they could still be accessed by an attacker with access to network routers or bridges. Using multi-link service discovery solutions [RFC7558], external attackers have to be taken into consideration as well, e.g., when relaying multicast messages to other links.
クライアントアイデンティティプライバシー、正しくアドレス指定されていない場合は、パッシブ攻撃者によって除算できます（セクション2を参照）。必要なパッシブ攻撃者の種類は、利用可能なサービス情報を作成する手段によって異なります。マルチキャストメッセージを介して伝達された情報は、オンリンク攻撃者によって取得できます。ユニキャストメッセージはアクセスするのが難しいが、送信が暗号化されていない場合は、ネットワークルータまたはブリッジにアクセスすることで、攻撃者によってアクセスされることがあります。マルチリンクサービス発見ソリューションの使用[RFC7558]、外部攻撃者は、例えばマルチキャストメッセージを他のリンクに中継するときにも考慮に入れる必要があります。
Server identity privacy can be thwarted by a passive attacker in the same way as client identity privacy. Additionally, active attackers querying for information have to be taken into consideration as well. This is mainly relevant for unicast-based discovery, where listening to discovery traffic requires a MITM attacker; however, an external active attacker might be able to learn the server identity by just querying for service information, e.g., via DNS.
サーバーIDのプライバシーは、クライアントIDのプライバシーと同じ方法でパッシブ攻撃者によって除算されます。さらに、情報を照会するアクティブな攻撃者も考慮に入れる必要があります。これは主にユニキャストベースの発見に関連しており、発見トラフィックを聴くとMITM攻撃者が必要です。ただし、外部のアクティブ攻撃者は、サービス情報を照会するだけで、DNSを介してサーバーのIDを学習できる可能性があります。
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It allows nodes to publish the availability of an instance of a service by inserting specific records in the DNS ([RFC1033], [RFC1034], and [RFC1035]) or by publishing these records locally using multicast DNS (mDNS) [RFC6762]. Available services are described using three types of records:
DNSベースのサービス検出（DNS-SD）は[RFC6763]で定義されています。ノードは、DNS（[RFC1033]、[RFC1034]、[RFC1035]）に特定のレコードを挿入するか、またはマルチキャストDNS（MDNS）[RFC6762]を使用してローカルに発行することで、サービスのインスタンスの可用性を公開できます。利用可能なサービスは、3種類のレコードを使用して説明されています。
PTR Record Associates a service type in the domain with an "instance" name of this service type.
PTRレコードドメイン内のサービスタイプをこのサービスタイプの「インスタンス」名に関連付けます。
SRV Record Provides the node name, port number, priority and weight associated with the service instance, in conformance with [RFC2782].
SRVレコード[RFC2782]に準拠して、サービスインスタンスに関連付けられているノード名、ポート番号、優先順位、および重みを提供します。
TXT Record Provides a set of attribute-value pairs describing specific properties of the service instance.
TXTレコードは、サービスインスタンスの特定のプロパティを記述する一連の属性値ペアを提供します。
In the first phase of discovery, clients obtain all PTR records associated with a service type in a given naming domain. Each PTR record contains a Service Instance Name defined in Section 4 of [RFC6763]:
ディスカバリの最初のフェーズでは、クライアントは指定された命名ドメイン内のサービスタイプに関連付けられているすべてのPTRレコードを取得します。各PTRレコードには、[RFC6763]のセクション4で定義されているサービスインスタンス名が含まれています。
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is meant to convey enough information for users of discovery clients to easily select the desired service instance. Nodes that use DNS-SD over mDNS [RFC6762] in a mobile environment will rely on the specificity of the instance name to identify the desired service instance. In our example of users wanting to upload pictures to a laptop in an Internet cafe, the list of available service instances may look like:
サービスインスタンス名の<instance>部分は、ディスカバリークライアントのユーザーに十分な情報を伝達して、目的のサービスインスタンスを簡単に選択するためのものです。モバイル環境でDNS-SDを使用するノード[RFC6762]は、インスタンス名の特異性に依存して、目的のサービスインスタンスを識別します。インターネットカフェで写真をノートパソコンにアップロードしたいユーザーの例では、利用可能なサービスインスタンスのリストは次のようになります。
Alice's Images . _imageStore._tcp . local Alice's Mobile Phone . _presence._tcp . local Alice's Notebook . _presence._tcp . local Bob's Notebook . _presence._tcp . local Carol's Notebook . _presence._tcp . local
アリスの画像_imagestore._tcp。地元のアリスの携帯電話。_presence._tcp。地元のアリスのノートブック。_presence._tcp。ローカルボブのノートブック。_presence._tcp。地元のキャロルのノートブック。_presence._tcp。地元
Alice will see the list on her phone and understand intuitively that she should pick the first item. The discovery will "just work". (Note that our examples of service names conform to the specification in Section 4.1 of [RFC6763] but may require some character escaping when entered in conventional DNS software.)
Aliceは彼女の電話のリストを見ると、彼女が最初のアイテムを選ぶべきであることを直感的に理解します。ディスカバリーは「ただうまくいく」でしょう。（サービス名の例の例は、[RFC6763]のセクション4.1の仕様に準拠していますが、従来のDNSソフトウェアで入力したときに一部の文字のエスケープが必要な場合があります。）
However, DNS-SD/mDNS will reveal to anybody that Alice is currently visiting the Internet cafe. It further discloses the fact that she uses two devices, shares an image store, and uses a chat application supporting the _presence protocol on both of her devices. She might currently chat with Bob or Carol, as they are also using a _presence supporting chat application. This information is not just available to devices actively browsing for and offering services but to anybody passively listening to the network traffic, i.e., a passive on-link attacker.
しかし、DNS-SD / MDNSはアリスが現在インターネットカフェを訪れていることを認めています。さらに2つの装置を使用し、画像ストアを共有し、その両方のデバイスで_Presenceプロトコルをサポートするチャットアプリケーションを使用することがさらに開示されている。彼女は現在BOBやCarolとチャットしているかもしれません。この情報は、サービスを積極的に閲覧して提供する機器が利用できるだけでなく、ネットワークトラフィック、すなわちパッシブオンリンク攻撃者を受動的に聴いています。
There is, of course, also no authentication requirement to claim a particular instance name, so an active attacker can provide resources that claim to be Alice's but are not.
もちろん、特定のインスタンス名を請求するための認証要件もありません。したがって、アクティブな攻撃者は、アリスの主張を主張するリソースを提供できますが、そうではありません。
The SRV records contain the DNS name of the node publishing the service. Typical implementations construct this DNS name by concatenating the "hostname" of the node with the name of the local domain. The privacy implications of this practice are reviewed in [RFC8117]. Depending on naming practices, the hostname is either a strong identifier of the device or, at a minimum, a partial identifier. It enables tracking of both the device and, by extension, the device's owner.
SRVレコードには、サービスを公開するノードのDNS名が含まれています。典型的な実装は、ノードの「hostname」をローカルドメインの名前で連結することによってこのDNS名を構築します。この慣行のプライバシーの意味は[RFC8117]で見直されています。ネーミング方法に応じて、ホスト名はデバイスの強い識別子、または最小限の部分識別子のいずれかです。それはデバイスの両方を追跡し、デバイスの所有者である。
The TXT record's attribute-value pairs contain information on the characteristics of the corresponding service instance. This in turn reveals information about the devices that publish services. The amount of information varies widely with the particular service and its implementation:
TXTレコードの属性値ペアには、対応するサービスインスタンスの特性に関する情報が含まれています。これにより、サービスを公開するデバイスに関する情報が明らかになります。情報量は特定のサービスとその実装に大きく異なります。
* Some attributes, such as the paper size available in a printer, are the same on many devices and thus only provide limited information to a tracker.
* プリンタで使用可能な用紙サイズなどの属性は、多くのデバイスで同じであり、したがってトラッカーに限られた情報しか提供されません。
* Attributes that have free-form values, such as the name of a directory, may reveal much more information.
* ディレクトリの名前などの自由形式の値を持つ属性は、もっと多くの情報を明らかにするかもしれません。
Combinations of individual attributes have more information power than specific attributes and can potentially be used for "fingerprinting" a specific device.
個々の属性の組み合わせは特定の属性よりも多くの情報電力を持ち、特定のデバイスを「フィンガープリント」に使用することができます。
Information contained in TXT records not only breaches privacy by making devices trackable but might directly contain private information about the user. For instance, the _presence service reveals the "chat status" to everyone in the same network. Users might not be aware of that.
TXTレコードに含まれる情報は、デバイスを追跡可能にすることによってプライバシーを侵害するだけでなく、ユーザーに関する個人情報を直接含めることができます。たとえば、_Presenceサービスは、同じネットワーク内のすべての人に「チャットステータス」を表示します。ユーザーはそれに気付かないかもしれません。
Further, TXT records often contain version information about services, allowing potential attackers to identify devices running exploit-prone versions of a certain service.
さらに、TXTレコードにはサービスに関するバージョン情報が含まれており、攻撃者の潜在的な攻撃者が特定のサービスのエクスプロイトによるバージョンを実行しているデバイスを識別できるようになります。
The combination of information published in DNS-SD has the potential to provide a "fingerprint" of a specific device. Such information includes:
DNS-SDに公開されている情報の組み合わせは、特定の装置の「指紋」を提供する可能性があります。そのような情報は次のとおりです。
* A list of services published by the device, which can be retrieved because the SRV records will point to the same hostname.
* SRVレコードが同じホスト名を指しているため、デバイスによって公開されたサービスのリストを取得できます。
* Specific attributes describing these services.
* これらのサービスを記述する特定の属性。
* Port numbers used by the services.
* サービスによって使用されるポート番号。
* Priority and weight attributes in the SRV records.
* SRVレコードの優先属性と重み属性
This combination of services and attributes will often be sufficient to identify the version of the software running on a device. If a device publishes many services with rich sets of attributes, the combination may be sufficient to identify the specific device and track its owner.
サービスと属性のこの組み合わせは、デバイス上で実行されているソフトウェアのバージョンを識別するのに十分です。デバイスが豊富な属性セットを持つ多くのサービスを公開した場合、その組み合わせは特定のデバイスを識別して所有者を追跡するのに十分です。
An argument is sometimes made that devices providing services can be identified by observing the local traffic and that trying to hide the presence of the service is futile. However, there are good reasons for the discovery service layer to avoid unnecessary exposure:
サービスを提供するデバイスを提供することができ、サービスの存在を隠そうとしていることは無益であることが時には行われることがあります。ただし、ディスカバリーサービス層が不要な露出を避けるための良い理由があります。
1. Providing privacy at the discovery layer is of the essence for enabling automatically configured privacy-preserving network applications. Application layer protocols are not forced to leverage the offered privacy, but if device tracking is not prevented at the deeper layers, including the service discovery layer, obfuscating a certain service's protocol at the application layer is futile.
1. 発見層でプライバシーを提供することは、自動的に構成されたプライバシー保存ネットワークアプリケーションを有効にするためのエッセンスです。アプリケーション層プロトコルは、提供されたプライバシーを活用することを余儀なくされていませんが、サービス発見層を含むより深い層でデバイスの追跡が妨げられていない場合は、特定のサービス層で特定のサービスのプロトコルを難いしません。
2. Further, in the case of mDNS-based discovery, even if the application layer does not protect privacy, services are typically provided via unicast, which requires a MITM attacker, whereas identifying services based on multicast discovery messages just requires an on-link attacker.
2. さらに、MDNSベースの発見の場合には、アプリケーション層がプライバシーを保護していなくても、MITM攻撃者が必要なのに対し、マルチキャスト検出メッセージに基づくサービスを識別するだけでは、Unicastを介してサービスが提供されています。
The same argument can be extended to say that the pattern of services offered by a device allows for fingerprinting the device. This may or may not be true, since we can expect that services will be designed or updated to avoid leaking fingerprints. In any case, the design of the discovery service should avoid making a bad situation worse and should, as much as possible, avoid providing new fingerprinting information.
同じ議論は、装置によって提供されるサービスのパターンが装置を指紋することを可能にすると言えるように拡張することができる。これは、サービスを漏らさないようにサービスが設計または更新されることを期待できるので、本当ではないかもしれません。いずれにせよ、発見サービスの設計は悪い状況を悪化させることを避けるべきであり、できるだけ多くの指紋情報を提供しないでください。
The consumers of services engage in discovery and in doing so reveal some information, such as the list of services they are interested in and the domains in which they are looking for the services. When the clients select specific instances of services, they reveal their preference for these instances. This can be benign if the service type is very common, but it could be more problematic for sensitive services, such as some private messaging services.
サービスの消費者は発見に従事しているので、彼らが興味のあるサービスのリストやサービスを探しているドメインなどの情報を明らかにします。クライアントがServicesの特定のインスタンスを選択すると、これらのインスタンスに対する優先順位が表示されます。サービスの種類が非常に一般的な場合、これは良性になる可能性がありますが、プライベートメッセージングサービスなど、機密サービスにとってより問題がある可能性があります。
One way to protect clients would be to somehow encrypt the requested service types. Of course, just as we noted in Section 3.2.5, traffic analysis can often reveal the service.
クライアントを保護する1つの方法は、要求されたサービスタイプを暗号化することです。もちろん、3.2.5項で述べたように、交通分析はしばしばサービスを明らかにすることができます。
For each of the operations described above, we must also consider security threats we are concerned about.
上記の各操作について、私達は私達が関心のあるセキュリティの脅威を考慮しなければなりません。
Can devices (both servers and clients) trust the information they receive? Has it been modified in flight by an adversary? Can devices trust the source of the information? Is the source of information fresh, i.e., not replayed? Freshness may or may not be required depending on whether the discovery process is meant to be online. In some cases, publishing discovery information to a shared directory or registry, rather than to each online recipient through a broadcast channel, may suffice.
デバイス（サーバーとクライアントの両方）が受信する情報を信頼できますか？それは敵対者によって飛行中で修正されましたか？デバイスは情報の情報源を信頼できますか？新鮮な情報の源です、すなわち再生されていませんか？発見プロセスがオンラインになることを意図しているかどうかに応じて、鮮度が必要とされない場合があります。場合によっては、ブロードキャストチャネルを介して各オンライン受信者ではなく、発見情報を共有ディレクトリまたはレジストリに公開することが十分であればよい。
Confidentiality is about restricting information access to only authorized individuals. Ideally, this should only be the appropriate trusted parties, though it can be challenging to define who are "the appropriate trusted parties." In some use cases, this may mean that only mutually authenticated and trusting clients and servers can read messages sent for one another. The process of service discovery in particular is often used to discover new entities that the device did not previously know about. It may be tricky to work out how a device can have an established trust relationship with a new entity it has never previously communicated with.
機密性は、許可された個人だけへの情報アクセスを制限することです。理想的には、これは適切な信頼できる締約国であるべきですが、「適切な信頼関係者」であるのかを定義することは困難です。使用例によっては、これは相互に認証され信頼できるクライアントとサーバーのみが互いに送信されたメッセージを読み取ることができることを意味します。特にサービス発見のプロセスは、デバイスが以前に知らなかった新しいエンティティを発見するためによく使用されます。デバイスが以前に通信したことがない新しいエンティティとの確立された信頼関係を持つことができる方法を見つけるのは難しいかもしれません。
It can be tempting to use (publicly computable) hash functions to obscure sensitive identifiers. This transforms a sensitive unique identifier, such as an email address, into a "scrambled" but still unique identifier. Unfortunately, simple solutions may be vulnerable to offline dictionary attacks.
機密識別子を覆い隠すために（公に計算可能な）ハッシュ関数を使用することを誘惑することができます。これは、電子メールアドレスなどの敏感な固有の識別子を「スクランブル」に変換しますが、まだ一意の識別子に変換されます。残念ながら、単純な解決策はオフライン辞書攻撃に対して脆弱な場合があります。
In any protocol where the receiver of messages has to perform cryptographic operations on those messages, there is a risk of a brute-force flooding attack causing the receiver to expend excessive amounts of CPU time and, where applicable, battery power just processing and discarding those messages.
メッセージの受信機がそれらのメッセージに対して暗号化操作を実行する必要がある任意のプロトコルでは、受信者に過剰な量のCPU時間を費やし、該当する場合、電池の電力を処理して廃棄するために受信機に急激なフラッディング攻撃が発生するリスクがあります。メッセージ
Also, amplification attacks have to be taken into consideration. Messages with larger payloads should only be sent as an answer to a query sent by a verified client.
また、増幅攻撃を考慮する必要があります。より大きなペイロードを持つメッセージは、検証済みクライアントによって送信されたクエリに対する答えとしてのみ送信されるべきです。
Sender impersonation is an attack wherein messages, such as service offers, are forged by entities who do not possess the corresponding secret key material. These attacks may be used to learn the identity of a communicating party, actively or passively.
送信者の偽装は、サービスオファーなどのメッセージが対応する秘密鍵素材を持たないエンティティによって採取されている攻撃です。これらの攻撃は、通信者の身元、積極的または受動的に学習するために使用され得る。
Deniability of sender activity, e.g., of broadcasting a discovery request, may be desirable or necessary in some use cases. This property ensures that eavesdroppers cannot prove senders issued a specific message destined for one or more peers.
送信者活動の否定性、例えば発見要求をブロードキャストすることは、いくつかの用途の場合において望ましいかまたは必要とされるかもしれない。このプロパティは、盗聴者が送信者が1つ以上のピア宛ての特定のメッセージを発行したことを証明できないようにします。
Many modern devices, especially battery-powered devices, use power management techniques to conserve energy. One such technique is for a device to transfer information about itself to a proxy, which will act on behalf of the device for some functions while the device itself goes to sleep to reduce power consumption. When the proxy determines that some action is required, which only the device itself can perform, the proxy may have some way to wake the device, as described for example in [SLEEP-PROXY].
多くの現代の装置、特に電池式装置は、電力管理技術を使用してエネルギーを節約します。そのような技術の1つは、デバイス自体がスリープ状態になる間、デバイス自体が消費電力を低減するためにスリープ状態になる間、それ自体に関する情報をプロキシに転送するための装置が提供される。プロキシが何らかの操作が必要であると判断した場合、デバイス自体だけが実行できると判断した場合、プロキシは、例えば[Sleep-Proxy]で説明されているように、デバイスを起動するための何らかの方法を持つことができます。
In many cases, the device may not trust the network proxy sufficiently to share all its confidential key material with the proxy. This poses challenges for combining private discovery that relies on per-query cryptographic operations with energy-saving techniques that rely on having (somewhat untrusted) network proxies answer queries on behalf of sleeping devices.
多くの場合、デバイスはネットワークプロキシをすべての機密鍵素材をプロキシで共有するのに十分に信頼できないことがあります。これは、クエリごとの暗号化操作に依存するプライベートディスカバリを組み合わせることに依存しています。
Creating a discovery protocol that has the desired security properties may result in a design that is not efficient. To perform the necessary operations, the protocol may need to send and receive a large number of network packets or require an inordinate amount of multicast transmissions. This may consume an unreasonable amount of network capacity, particularly problematic when it is a shared wireless spectrum. Further, it may cause an unnecessary level of power consumption, which is particularly problematic on battery devices and may result in the discovery process being slow.
目的のセキュリティプロパティを持つ検出プロトコルを作成すると、効率的ではないデザインが発生する可能性があります。必要な操作を実行するために、プロトコルは多数のネットワークパケットを送受信するか、または不従順のマルチキャスト送信を必要とする必要があるかもしれません。これは、それが共有された無線スペクトルである場合には、不当な量のネットワーク容量を消費する可能性があります。さらに、不要なレベルの消費電力を引き起こす可能性があり、これは電池装置に特に問題があるため、発見プロセスが遅くなる可能性がある。
It is a difficult challenge to design a discovery protocol that has the property of obscuring the details of what it is doing from unauthorized observers while also managing to perform efficiently.
不正なオブザーバーから実行している内容の詳細を隠しながら効率的に実行することができないという特性を持つという発見プロトコルを設計するのは難しい課題です。
One of the challenges implicit in the preceding discussions is that whenever we discuss "trusted entities" versus "untrusted entities", there needs to be some way that trust is initially established to convert an "untrusted entity" into a "trusted entity".
前述の議論の中の課題の1つは、「信頼できるエンティティ」と「信頼されていないエンティティ」について議論するたびに、信頼が最初に「信頼されていないエンティティ」を「信頼できるエンティティ」に変換するために確立されることが何らかの方法であることです。
The purpose of this document is not to define the specific way in which trust can be established. Protocol designers may rely on a number of existing technologies, including PKI, Trust On First Use (TOFU), or the use of a short passphrase or PIN with cryptographic algorithms, such as Secure Remote Password (SRP) [RFC5054] or a Password-Authenticated Key Exchange like J-PAKE [RFC8236] using a Schnorr Non-interactive Zero-Knowledge Proof [RFC8235].
この文書の目的は、信頼を確立できる特定の方法を定義することではありません。プロトコル設計者は、PKI、最初の使用に関する信頼（TOFU）、またはセキュアリモートパスワード（SRP）[RFC5054]またはパスワードなどの暗号化アルゴリズムを備えた短いパスフレーズまたはピンの使用を含む、いくつかの既存のテクノロジに依存する可能性があります。J-Pakeのような認証された鍵交換[RFC8236] Schnorr非対話型ゼロ知識証明[RFC8235]。
Protocol designers should consider a specific usability pitfall when trust is established immediately prior to performing discovery. Users will have a tendency to "click OK" in order to achieve their task. This implicit vulnerability is avoided if the trust establishment requires more significant participation of the user, such as entering a password or PIN.
プロトコル設計者は、発見を実行する直前に信頼が確立されたときに特定のユーザビリティの落とし穴を考慮する必要があります。ユーザーは自分のタスクを達成するために「OK」を「クリック」する傾向があります。信頼確立が、パスワードやピンの入力など、ユーザーの重要な参加を必要とする場合、この暗黙の脆弱性は回避されます。
Trust establishment may depend on external parties. Optionally, this might involve synchronous communication. Systems that have such a dependency may be attacked by interfering with communication to external dependencies. Where possible, such dependencies should be minimized. Local trust models are best for secure initialization in the presence of active attackers.
信頼確立は外部の関係者によって異なります。任意選択で、これは同期通信を含むかもしれません。そのような依存関係を有するシステムは、外部依存関係への通信を妨害することによって攻撃され得る。可能であれば、そのような依存関係は最小限に抑えるべきです。地元の信頼モデルは、アクティブな攻撃者の存在下での安全な初期化に最適です。
Given the considerations discussed in the previous sections, we state requirements for privacy preserving DNS-SD in the following subsections.
前のセクションで説明した考慮事項を考慮すると、以下のサブセクションでDNS-SDを保存するプライバシーの要件を述べています。
Defining a solution according to these requirements is intended to lead to a solution that does not transmit privacy-violating DNS-SD messages and further does not open pathways to new attacks against the operation of DNS-SD.
これらの要件に従って解決策を定義することは、プライバシーに違反しているDNS-SDメッセージを送信しないソリューションにつながり、さらにDNS-SDの動作に対する新しい攻撃に対して経路を開くことを意図しています。
However, while this document gives advice on which privacy protecting mechanisms should be used on deeper-layer network protocols and on how to actually connect to services in a privacy-preserving way, stating corresponding requirements is out of the scope of this document. To mitigate attacks against privacy on lower layers, both servers and clients must use privacy options available at lower layers and, for example, avoid publishing static IPv4 or IPv6 addresses or static IEEE 802 Media Access Control (MAC) addresses. For services advertised on a single network link, link-local IP addresses should be used; see [RFC3927] and [RFC4291] for IPv4 and IPv6, respectively. Static servers advertising services globally via DNS can hide their IP addresses from unauthorized clients using the split mode topology shown in Encrypted Server Name Indication [ESNI]. Hiding static MAC addresses can be achieved via MAC address randomization (see [RFC7844]).
ただし、このドキュメントでは、より深層ネットワークプロトコルでプライバシー保護メカニズムを使用するアドバイスと、実際にプライバシー保存方法で実際にサービスに接続する方法について、対応する要件を述べることがこの文書の範囲外です。下位層のプライバシーに対する攻撃を軽減するためには、サーバーとクライアントの両方を下位レイヤで使用可能なプライバシーオプションを使用する必要があります。たとえば、静的IPv4またはIPv6アドレスまたは静的IEEE 802メディアアクセス制御（MAC）アドレスを公開しないでください。単一のネットワークリンクでアドバタイズされたサービスの場合、Link-Local IPアドレスを使用する必要があります。IPv4とIPv6の[RFC3927]と[RFC4291]を参照してください。DNSを介してグローバルにサービスを広告する静的サーバーは、暗号化されたサーバー名表示[ESNI]に示されているスプリットモードトポロジを使用して、不正なクライアントからIPアドレスを隠すことができます。静的MACアドレスを隠すことは、MACアドレスのランダム化を介して達成することができる（[RFC7844]参照）。
For all three scenarios described in Section 3.1, client privacy requires DNS-SD messages to:
セクション3.1で説明されている3つのシナリオすべての場合、クライアントのプライバシーにはDNS-SDメッセージが必要です。
1. Avoid disclosure of the client's identity, either directly or via inference, to nodes other than select servers.
1. 直接または推論を介して、SELECTサーバー以外のノードへのクライアントのIDの開示を避けてください。
2. Avoid exposure of linkable identifiers that allow tracing client devices.
2. トレースクライアントデバイスを許可するリンク可能な識別子を露出させないでください。
3. Avoid disclosure of the client's interest in specific service instances or service types to nodes other than select servers.
3. 特定のサービスインスタンスまたはサービスタイプへのクライアントの関心の開示を選択して、SELECTサーバー以外のノードへのアクセスを避けます。
When listing and resolving services via current DNS-SD deployments, clients typically disclose their interest in specific services types and specific instances of these types, respectively.
現在のDNS-SDデプロイメントを介してサービスをリストおよび解決するとき、クライアントは通常、特定のサービスタイプおよびこれらの型の特定のインスタンスへの関心を開示しています。
In addition to the exposure and disclosure risks noted above, protocols and implementations will have to consider fingerprinting attacks (see Section 3.2.5) that could retrieve similar information.
上記のばく露および開示のリスクに加えて、プロトコルと実装は、同様の情報を取得できる指紋攻撃（セクション3.2.5を参照）を検討する必要があります。
Servers like the "printer" discussed in Section 3.1.1 are public, but the servers discussed in Sections 3.1.2 and 3.1.3 are, by essence, private. Server privacy requires DNS-SD messages to:
3.1.1項で議論されている「プリンタ」のようなサーバーは公開されていますが、セクション3.1.2と3.1.3で説明されているサーバーは、本質的に、プライベートによって異なります。サーバーのプライバシーには、DNS-SDメッセージが必要です。
1. Avoid disclosure of the server's identity, either directly or via inference, to nodes other than authorized clients. In particular, servers must avoid publishing static identifiers, such as hostnames or service names. When those fields are required by the protocol, servers should publish randomized values. (See [RFC8117] for a discussion of hostnames.)
1. 直接または推論を介して、許可されたクライアント以外のノードに、サーバーの身元の開示を避けてください。特に、サーバーは、ホスト名やサービス名などの静的識別子を公開しないようにしてください。これらのフィールドがプロトコルによって必要とされると、サーバーはランダム化された値を発行する必要があります。（ホスト名の説明については、[RFC8117]を参照してください。）
2. Avoid exposure of linkable identifiers that allow tracing servers.
2. トレースサーバーを許可するリンク可能な識別子を露出させないでください。
3. Avoid disclosure to unauthorized clients of Service Instance Names or service types of offered services.
3. 提供されたサービスのサービスインスタンス名またはサービスタイプの不正なクライアントへの開示を避けてください。
4. Avoid disclosure to unauthorized clients of information about the services they offer.
4. 彼らが提供するサービスに関する情報の不正なクライアントへの開示を避けてください。
5. Avoid disclosure of static IPv4 or IPv6 addresses.
5. 静的IPv4またはIPv6アドレスの開示を避けてください。
When offering services via current DNS-SD deployments, servers typically disclose their hostnames (SRV, A/AAAA), instance names of offered services (PTR, SRV), and information about services (TXT). Heeding these requirements protects a server's privacy on the DNS-SD level.
現在のDNS-SDデプロイメントを介してサービスを提供する場合、サーバーは通常、それらのホスト名（SRV、A / AAAA）、提供されたサービスのインスタンス名（PTR、SRV）、およびサービスに関する情報（TXT）を開示します。これらの要件は、DNS-SDレベルに関するサーバーのプライバシーを保護します。
The current DNS-SD user interfaces present the list of discovered service names to the users and let them pick a service from the list. Using random identifiers for service names renders that UI flow unusable. Privacy-respecting discovery protocols will have to solve this issue, for example, by presenting authenticated or decrypted service names instead of the randomized values.
現在のDNS-SDユーザーインターフェイスは、検出されたサービス名のリストをユーザーに提示し、リストからサービスを選択できます。サービス名のランダム識別子を使用すると、UI Flowが使用できないことができます。プライバシー尊重発見プロトコルは、例えば、無作為化された値の代わりに認証されたまたは復号化されたサービス名を提示することによって、この問題を解決する必要があります。
In order to be secure and feasible, a DNS-SD privacy extension needs to consider security and operational requirements including:
安全性と実現可能であるためには、DNS-SDプライバシー拡張機能は、セキュリティと運用上の要件を含む必要があります。
1. Avoiding significant CPU overhead on nodes or significantly higher network load. Such overhead or load would make nodes vulnerable to denial-of-service attacks. Further, it would increase power consumption, which is damaging for IoT devices.
1. ノードでかなりのCPUオーバーヘッドを回避するか、または大幅に高いネットワーク負荷を回避する。そのようなオーバーヘッドまたは負荷は、ノードをサービス拒否攻撃に対して脆弱にするでしょう。さらに、IOTデバイスの損傷である消費電力を増大させるであろう。
2. Avoiding designs in which a small message can trigger a large amount of traffic towards an unverified address, as this could be exploited in amplification attacks.
2. 小さなメッセージが未確認のアドレスに向かって大量のトラフィックを引き起こす可能性があるデザインを避けることは、これが増幅攻撃で利用される可能性があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。
[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-07, June 1, 2020, <https://tools.ietf.org/html/draft-ietf-tls-esni-07>.
[ESNI] Rescorla、E.、OKU、K。、SULLIVAN、N.、およびCA WOOD、「TLS暗号化クライアントHello」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-ESNI-07、6月1日2020、<https://tools.ietf.org/html/draft-ietf-tls-esni-07>。
[K17] Kaiser, D., "Efficient Privacy-Preserving Configurationless Service Discovery Supporting Multi-Link Networks", August 2017, <https://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
[K17] Kaiser、D.、「効率的なプライバシー保護のためのマルチリンクネットワークをサポートするマルチリンクネットワーク」、2017年8月、<https://nbn-resolving.de/urn:de:de:32757>。
[KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, September 2014, <https://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=7011331>.
[KW14A] Kaiser、D.およびM. WaldVogel、「マルチキャストDNSサービスの発見へのプライバシーの追加」、DOI 10.1109 / Trustcom.2014.107、2014年9月、<https：//ieeexplore.iee.org/xpl/ articledetails.jsp？Arnumber= 7011331>。
[KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving Multicast DNS Service Discovery", DOI 10.1109/HPCC.2014.141, August 2014, <https://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=7056899>.
[KW14B]カイザー、D.およびM. WaldVogel、「効率的なプライバシー保護マルチキャストDNSサービス発見」、DOI 10.1109 / HPCC.2014.141、2014年8月、<https：//ieeexplore.iee.org/xpl/ articledetails.jsp？Arnumber= 7056899>。
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987, <https://www.rfc-editor.org/info/rfc1033>.
[RFC1033]ロッタ、M.、「ドメイン管理者オペレーションガイド」、RFC 1033、DOI 10.17487 / RFC1033、1987年11月、<https：//www.rfc-editor.org/info/rfc1033>。
[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>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：//www.rfc-editor.org/info/rfc2782>。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.
[RFC3927]チェシャー、S、ABOBA、B.、およびE.Guttman、「IPv4リンクローカルアドレスの動的構成」、RFC 3927、DOI 10.17487 / RFC3927、2005年5月、<https：//www.rfc-編集者.ORG / INFO / RFC3927>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/info/rfc5054>.
[RFC5054] Taylor、D.、Wu、T.、MavrogianNopoulos、N.、およびT. Perrin、「TLS認証用の安全なリモートパスワード（SRP）プロトコルの使用」、RFC 5054、DOI 10.17487 / RFC5054、2007年11月、<https://www.rfc-editor.org/info/rfc5054>。
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, <https://www.rfc-editor.org/info/rfc7558>.
[RFC7558] Lynn、K.、Cheshire、S.、Blanchet、M.、およびD. Migault、「スケーラブルDNSベースのサービス発見（DNS-SD）/マルチキャストDNS（MDNS）拡張機能の要件」、RFC 7558、DOI2017487 / RFC7558、2015年7月、<https：//www.rfc-editor.org/info/rfc7558>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T.、およびKrishnan、「DHCPクライアントの匿名性プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<https：//www.rfc-editor.org/情報/ RFC7844>。
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017, <https://www.rfc-editor.org/info/rfc8117>.
[RFC8117] Huitema、C、Thaler、D.、およびR.冬、「現在のホスト名の実践」、RFC 8117、DOI 10.17487 / RFC8117、2017年3月、<https：//www.rfc-editor.org/情報/ RFC8117>。
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/info/rfc8235>.
[RFC8235] HAO、F、ED。、「SCHNORT非対話型ゼロ知識証明」、RFC 8235、DOI 10.17487 / RFC8235、2017年9月、<https：//www.rfc-editor.org/info/rfc8235>。
[RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 2017, <https://www.rfc-editor.org/info/rfc8236>.
[RFC8236] HAO、F、ED。、「J-Pake：ジャグリングによるパスワード認証鍵交換」、RFC 8236、DOI 10.17487 / RFC8236、2017年9月、<https：//www.rfc-editor.org/info/ RFC8236>。
[SLEEP-PROXY] Cheshire, S., "Understanding Sleep Proxy Service", December 2009, <http://stuartcheshire.org/SleepProxy/index.html>.
[Sleep-Proxy] Cheshire、S。、2009年12月、<http://stuartchehire.org/sleepproxy/index.html>。
[SRP] Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", Work in Progress, Internet-Draft, draft-ietf-dnssd-srp-04, July 13, 2020, <https://tools.ietf.org/html/draft-ietf-dnssd-srp-04>.
[SRP]レモン、T.およびS.チェシャー、「DNSベースのサービス発見のためのサービス登録プロトコル」、進行中の作業、インターネットドラフト、ドラフト - IETF-DNSSD-SRP-04、2020年7月13日、<https：//tools.ietf.org/html/draft-ietf-dnssd-srp-04>。
Acknowledgments
謝辞
This document incorporates many contributions from Stuart Cheshire and Chris Wood. Thanks to Florian Adamsky for extensive review and suggestions on the organization of the threat model. Thanks to Barry Leiba for an extensive review. Thanks to Roman Danyliw, Ben Kaduk, Adam Roach, and Alissa Cooper for their comments during IESG review.
この文書はStuart CheshireとChris Woodから多くの貢献を取り入れています。豊富なレビューと脅威モデルの組織に関する提案のためのフロリアンアダムスキーに感謝します。広いレビューのためにBarry Leibaのおかげでお願いいたします。IESGレビュー中のコメントのために、Roman Danyliw、Ben Kaduk、Adam Roach、およびAlissa Cooperに感謝します。
Authors' Addresses
著者の住所
Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 United States of America
Christian Huitema Private Octopus Inc. Friday Harbour、WA 98250アメリカ合衆国
Email: huitema@huitema.net
URI: http://privateoctopus.com/
Daniel Kaiser University of Luxembourg 6, avenue de la Fonte L-4364 Esch-sur-Alzette Luxembourg
Daniel Kaiser Luxembourg大学6、Avenue de la Fonte L-4364 Esch-Sur-Alzetteルクセンブルク
Email: daniel.kaiser@uni.lu
URI: https://secan-lab.uni.lu/