[要約] RFC 8826は、WebRTC (Web Real-Time Communication) のセキュリティに関する考慮事項を扱っています。この文書の目的は、WebRTCを使用する際に発生する潜在的なセキュリティリスクを特定し、それらに対処するためのガイドラインを提供することです。利用場面としては、ブラウザ間でのリアルタイムの音声、ビデオ、データ共有を行うアプリケーションの開発者や、セキュリティ専門家が対象です。関連するRFCには、RFC 7742 (WebRTC Video Communicationの使用に関するガイドライン)、RFC 8839 (WebRTCのためのセキュリティアーキテクチャ) などがあります。これらの文書は、WebRTC技術の安全な実装と利用を支援するために相互に関連しています。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8826 Mozilla
Category: Standards Track January 2021
ISSN: 2070-1721
Security Considerations for WebRTC
WebRTCのセキュリティに関する考慮事項
Abstract
概要
WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.
WebRTCは、ブラウザーにデプロイできるリアルタイムアプリケーション（「Webでのリアルタイム通信」）で使用するためのプロトコルスイートです。このドキュメントでは、WebRTC脅威モデルを定義し、そのモデルにおけるWebRTCのセキュリティ脅威を分析します。
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.
このドキュメントは、インターネット技術特別調査委員会（IETF）の製品です。これは、IETFコミュニティのコンセンサスを表しています。パブリックレビューを受け、Internet Engineering Steering Group（IESG）による公開が承認されました。インターネット標準の詳細については、RFC7841のセクション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/rfc8826.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8826で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2021 IETFTrustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。この資料の一部の著作権を管理している人は、IETFトラストにそのような資料の変更を許可する権利を付与していない可能性があります。IETF標準プロセスの外部。そのような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントをIETF標準プロセスの外部で変更したり、その派生物をIETF標準プロセスの外部で作成したりすることはできません。RFCとして公開するか、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction
2. Terminology
3. The Browser Threat Model
3.1. Access to Local Resources
3.2. Same-Origin Policy
3.3. Bypassing SOP: CORS, WebSockets, and Consent to Communicate
4. Security for WebRTC Applications
4.1. Access to Local Devices
4.1.1. Threats from Screen Sharing
4.1.2. Calling Scenarios and User Expectations
4.1.2.1. Dedicated Calling Services
4.1.2.2. Calling the Site You're On
4.1.3. Origin-Based Security
4.1.4. Security Properties of the Calling Page
4.2. Communications Consent Verification
4.2.1. ICE
4.2.2. Masking
4.2.3. Backward Compatibility
4.2.4. IP Location Privacy
4.3. Communications Security
4.3.1. Protecting Against Retrospective Compromise
4.3.2. Protecting Against During-Call Attack
4.3.2.1. Key Continuity
4.3.2.2. Short Authentication Strings
4.3.2.3. Third-Party Identity
4.3.2.4. Page Access to Media
4.3.3. Malicious Peers
4.4. Privacy Considerations
4.4.1. Correlation of Anonymous Calls
4.4.2. Browser Fingerprinting
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
The Real-Time Communications on the Web (RTCWEB) Working Group has standardized protocols for real-time communications between Web browsers, generally called "WebRTC" [RFC8825]. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based [RFC3261] soft phones), WebRTC communications are directly controlled by some Web server. A simple case is shown below.
Web上のリアルタイム通信（RTCWEB）ワーキンググループは、一般に「WebRTC」[RFC8825]と呼ばれるWebブラウザ間のリアルタイム通信用の標準化されたプロトコルを持っています。WebRTCテクノロジーの主な使用例は、リアルタイムの音声通話やビデオ通話、Web会議、および直接データ転送です。ほとんどの従来のリアルタイムシステム（SIPベースの[RFC3261]ソフトフォンなど）とは異なり、WebRTC通信は一部のWebサーバーによって直接制御されます。簡単なケースを以下に示します。
+----------------+
| |
| Web Server |
| |
+----------------+
^ ^
/ \
HTTPS / \ HTTPS
or / \ or
WebSockets / \ WebSockets
v v
JS API JS API
+-----------+ +-----------+
| | Media | |
| Browser |<---------->| Browser |
| | | |
+-----------+ +-----------+
Alice Bob
Figure 1: A Simple WebRTC System
図1：単純なWebRTCシステム
In the system shown in Figure 1, Alice and Bob both have WebRTC-enabled browsers and they visit some Web server which operates a calling service. Each of their browsers exposes standardized JavaScript (JS) calling APIs (implemented as browser built-ins) which are used by the Web server to set up a call between Alice and Bob. The Web server also serves as the signaling channel to transport control messages between the browsers. While this system is topologically similar to a conventional SIP-based system (with the Web server acting as the signaling service and browsers acting as softphones), control has moved to the central Web server; the browser simply provides API points that are used by the calling service. As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server.
図1に示すシステムでは、アリスとボブはどちらもWebRTC対応のブラウザーを使用しており、通話サービスを操作するWebサーバーにアクセスします。それぞれのブラウザーは、アリスとボブの間の呼び出しをセットアップするためにWebサーバーによって使用される標準化されたJavaScript（JS）呼び出しAPI（ブラウザー組み込みとして実装）を公開します。Webサーバーは、ブラウザー間で制御メッセージを転送するためのシグナリングチャネルとしても機能します。このシステムは、トポロジ的には従来のSIPベースのシステム（Webサーバーがシグナリングサービスとして機能し、ブラウザーがソフトフォンとして機能する）と似ていますが、制御は中央のWebサーバーに移動しました。ブラウザは、呼び出し元のサービスで使用されるAPIポイントを提供するだけです。他のWebアプリケーションと同様に、WebサーバーはサーバーとブラウザーのJavaScriptの間でロジックを移動できますが、コードが実行されている場所に関係なく、最終的にはサーバーの制御下にあります。
It should be immediately apparent that this type of system poses new security challenges beyond those of a conventional Voice over IP (VoIP) system. In particular, it needs to contend with malicious calling services. For example, if the calling service can cause the browser to make a call at any time to any callee of its choice, then this facility can be used to bug a user's computer without their knowledge, simply by placing a call to some recording service. More subtly, if the exposed APIs allow the server to instruct the browser to send arbitrary content, then they can be used to bypass firewalls or mount denial-of-service (DoS) attacks. Any successful system will need to be resistant to this and other attacks.
このタイプのシステムは、従来のVoice over IP（VoIP）システムよりも新しいセキュリティ上の課題を提起していることがすぐに明らかになります。特に、悪意のある通話サービスと戦う必要があります。たとえば、呼び出しサービスによってブラウザが選択した任意の呼び出し先にいつでも電話をかけることができる場合、この機能を使用すると、録音サービスに電話をかけるだけで、知らないうちにユーザーのコンピュータにバグを報告できます。さらに微妙なことに、公開されたAPIにより、サーバーがブラウザーに任意のコンテンツを送信するように指示できる場合、それらを使用してファイアウォールをバイパスしたり、サービス拒否（DoS）攻撃を仕掛けたりすることができます。成功するシステムは、この攻撃や他の攻撃に耐える必要があります。
A companion document [RFC8827] describes a security architecture intended to address the issues raised in this document.
コンパニオンドキュメント[RFC8827]は、このドキュメントで提起された問題に対処することを目的としたセキュリティアーキテクチャについて説明しています。
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]で説明されているように、ここに示すように、すべて大文字で表示される場合にのみ解釈されます。
The security requirements for WebRTC follow directly from the requirement that the browser's job is to protect the user. Huang et al. [huang-w2sp] summarize the core browser security guarantee as follows:
WebRTCのセキュリティ要件は、ブラウザの仕事がユーザーを保護することであるという要件に直接従っています。黄ら。[huang-w2sp]は、コアブラウザのセキュリティ保証を次のように要約しています。
Users can safely visit arbitrary web sites and execute scripts provided by those sites.
ユーザーは安全に任意のWebサイトにアクセスし、それらのサイトが提供するスクリプトを実行できます。
It is important to realize that this includes sites hosting arbitrary malicious scripts. The motivation for this requirement is simple: it is trivial for attackers to divert users to sites of their choice. For instance, an attacker can purchase display advertisements which direct the user (either automatically or via user clicking) to their site, at which point the browser will execute the attacker's scripts. Thus, it is important that it be safe to view arbitrarily malicious pages. Of course, browsers inevitably have bugs which cause them to fall short of this goal, but any new WebRTC functionality must be designed with the intent to meet this standard. The remainder of this section provides more background on the existing Web security model.
これには、任意の悪意のあるスクリプトをホストしているサイトが含まれることを理解することが重要です。この要件の動機は単純です。攻撃者がユーザーを選択したサイトに誘導するのは簡単です。たとえば、攻撃者は、ユーザーを（自動的に、またはユーザーのクリックを介して）自分のサイトに誘導するディスプレイ広告を購入できます。その時点で、ブラウザは攻撃者のスクリプトを実行します。したがって、悪意のある任意のページを安全に表示することが重要です。もちろん、ブラウザーには必然的にこの目標を達成できないバグがありますが、新しいWebRTC機能は、この標準を満たすことを目的として設計する必要があります。このセクションの残りの部分では、既存のWebセキュリティモデルの背景について説明します。
In this model, then, the browser acts as a Trusted Computing Base (TCB) both from the user's perspective and to some extent from the server's. While HTML and JavaScript provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below.
したがって、このモデルでは、ブラウザーは、ユーザーの観点からも、サーバーの観点からもある程度、トラステッドコンピューティングベース（TCB）として機能します。サーバーによって提供されるHTMLとJavaScriptにより、ブラウザーはさまざまなアクションを実行できますが、これらのスクリプトは、以下に詳述するように、ユーザーのコンピューターと相互の両方から分離するサンドボックスで動作します。
Conventionally, we refer to either Web attackers, who are able to induce you to visit their sites but do not control the network, or network attackers, who are able to control your network. Network attackers correspond to the [RFC3552] "Internet Threat Model". Note that in some cases, a network attacker is also a Web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker.
従来、私たちは、サイトへのアクセスを誘導できるがネットワークを制御できないWeb攻撃者、またはネットワークを制御できるネットワーク攻撃者のいずれかを指します。ネットワーク攻撃者は、[RFC3552]「インターネット脅威モデル」に対応しています。整合性保護を提供しないトランスポートプロトコルにより、ネットワークが通信ピアであるかのようにトラフィックを注入できるため、ネットワーク攻撃者がWeb攻撃者である場合もあることに注意してください。TLS、特にHTTPSはこれらの攻撃を防ぎますが、HTTP接続を分析するときは、トラフィックが攻撃者に向かっていると想定する必要があります。
While the browser has access to local resources such as keying material, files, the camera, and the microphone, it strictly limits or forbids Web servers from accessing those same resources. For instance, while it is possible to produce an HTML form which will allow file upload, a script cannot do so without user consent and in fact cannot even suggest a specific file (e.g., /etc/passwd); the user must explicitly select the file and consent to its upload. (Note: In many cases, browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks", as extensive research [cranor-wolf] shows that users are prone to consent under such circumstances.)
ブラウザは、キー情報、ファイル、カメラ、マイクなどのローカルリソースにアクセスできますが、Webサーバーがこれらの同じリソースにアクセスすることを厳しく制限または禁止しています。たとえば、ファイルのアップロードを許可するHTMLフォームを作成することは可能ですが、スクリプトはユーザーの同意なしに作成することはできず、実際には特定のファイル（/ etc / passwdなど）を提案することさえできません。ユーザーはファイルを明示的に選択し、アップロードに同意する必要があります。（注：多くの場合、ブラウザーは、「ここをクリックしてセキュリティチェックをバイパスする」というセマンティクスのダイアログを回避するように明示的に設計されています。これは、広範な調査[cranor-wolf]が、そのような状況ではユーザーが同意する傾向があることを示しています。）
Similarly, while Flash programs (SWFs) [SWF] can access the camera and microphone, they explicitly require that the user consent to that access. In addition, some resources simply cannot be accessed from the browser at all. For instance, there is no real way to run specific executables directly from a script (though the user can of course be induced to download executable files and run them).
同様に、Flashプログラム（SWF）[SWF]はカメラとマイクにアクセスできますが、ユーザーがそのアクセスに同意することを明示的に要求します。さらに、一部のリソースには、ブラウザからまったくアクセスできません。たとえば、スクリプトから直接特定の実行可能ファイルを実行する実際の方法はありません（ただし、ユーザーはもちろん、実行可能ファイルをダウンロードして実行するように誘導できます）。
Many other resources are accessible but isolated. For instance, while scripts are allowed to make HTTP requests via the fetch() API (see [fetch]) when requests are made to a server other than from the same *origin* from whence the script came [RFC6454] they are not able to read the responses. Cross-Origin Resource Sharing (CORS) [fetch] and WebSockets [RFC6455] provide an escape hatch from this restriction, as described below. This same-origin policy (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of their credentials) and server B (e.g., from DoS attacks).
他の多くのリソースはアクセス可能ですが、分離されています。たとえば、スクリプトが来た場所から同じ*オリジン*から以外のサーバーにリクエストが行われた場合、スクリプトはfetch（）API（[fetch]を参照）を介してHTTPリクエストを行うことができますが[RFC6454]、できません。応答を読みます。クロスオリジンリソースシェアリング（CORS）[フェッチ]とWebSocket [RFC6455]は、以下で説明するように、この制限からのエスケープハッチを提供します。この同一生成元ポリシー（SOP）は、サーバーAがユーザーのブラウザーを介してサーバーBに攻撃を仕掛けるのを防ぎ、ユーザー（資格情報の誤用など）とサーバーB（DoS攻撃など）の両方を保護します。
More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes. While there are techniques to allow them to interact, those interactions generally must be mutually consensual (by each site) and are limited to certain channels. For instance, multiple pages/browser panes from the same origin can read each other's JS variables, but pages from different origins -- or even IFRAMEs from different origins on the same page -- cannot.
より一般的には、SOPは、各サイトのスクリプトを独自の分離されたサンドボックスで実行するように強制します。それらが相互作用することを可能にする技術がありますが、それらの相互作用は一般に（各サイトによって）相互に合意する必要があり、特定のチャネルに制限されます。たとえば、同じオリジンの複数のページ/ブラウザペインは、互いのJS変数を読み取ることができますが、異なるオリジンのページ、または同じページの異なるオリジンのIFRAMEでさえも読み取ることができません。
While SOP serves an important security function, it also makes it inconvenient to write certain classes of applications. In particular, mash-ups, in which a script from origin A uses resources from origin B, can only be achieved via a certain amount of hackery. The W3C CORS spec [fetch] is a response to this demand. In CORS, when a script from origin A executes a potentially unsafe cross-origin request, the browser instead contacts the target server to determine whether it is willing to allow cross-origin requests from A. If it is so willing, the browser then allows the request. This consent verification process is designed to safely allow cross-origin requests.
SOPは重要なセキュリティ機能を提供しますが、特定のクラスのアプリケーションを作成することも不便にします。特に、オリジンAのスクリプトがオリジンBのリソースを使用するマッシュアップは、ある程度のハッカーを介してのみ実現できます。W3C CORS仕様[フェッチ]は、この要求への応答です。CORSでは、オリジンAからのスクリプトが潜在的に安全でないクロスオリジンリクエストを実行すると、ブラウザは代わりにターゲットサーバーに接続して、Aからのクロスオリジンリクエストを許可するかどうかを判断します。許可する場合、ブラウザは許可します。リクエスト。この同意確認プロセスは、クロスオリジンリクエストを安全に許可するように設計されています。
While CORS is designed to allow cross-origin HTTP requests, WebSockets [RFC6455] allows cross-origin establishment of transparent channels. Once a WebSockets connection has been established from a script to a site, the script can exchange any traffic it likes without being required to frame it as a series of HTTP request/ response transactions. As with CORS, a WebSockets transaction starts with a consent verification stage to avoid allowing scripts to simply send arbitrary data to another origin.
CORSはクロスオリジンHTTPリクエストを許可するように設計されていますが、WebSockets [RFC6455]はクロスオリジンの透過チャネルの確立を許可します。スクリプトからサイトへのWebSocket接続が確立されると、スクリプトは、一連のHTTP要求/応答トランザクションとしてフレーム化する必要なしに、好きなトラフィックを交換できます。CORSと同様に、WebSocketトランザクションは、スクリプトが任意のデータを別のオリジンに送信することを許可しないように、同意検証段階から始まります。
While consent verification is conceptually simple -- just do a handshake before you start exchanging the real data -- experience has shown that designing a correct consent verification system is difficult. In particular, Huang et al. [huang-w2sp] have shown vulnerabilities in the existing Java and Flash consent verification techniques and in a simplified version of the WebSockets handshake. It is important to be wary of CROSS-PROTOCOL attacks in which the attacking script generates traffic which is acceptable to some non-Web protocol state machine. In order to resist this form of attack, WebSockets incorporates a masking technique intended to randomize the bits on the wire, thus making it more difficult to generate traffic which resembles a given protocol.
同意の確認は概念的には単純ですが（実際のデータの交換を開始する前にハンドシェイクを行うだけです）、正しい同意の確認システムを設計することは難しいことが経験からわかっています。特に、Huang etal。[huang-w2sp]は、既存のJavaおよびFlashの同意検証手法と、WebSocketハンドシェイクの簡易バージョンに脆弱性を示しています。攻撃スクリプトが一部の非Webプロトコルステートマシンに受け入れられるトラフィックを生成するCROSS-PROTOCOL攻撃に注意することが重要です。この形式の攻撃に抵抗するために、WebSocketsには、ワイヤー上のビットをランダム化することを目的としたマスキング技術が組み込まれているため、特定のプロトコルに似たトラフィックを生成することがより困難になります。
As discussed in Section 1, allowing arbitrary sites to initiate calls violates the core Web security guarantee; without some access restrictions on local devices, any malicious site could simply bug a user. At minimum, then, it MUST NOT be possible for arbitrary sites to initiate calls to arbitrary locations without user consent. This immediately raises the question, however, of what should be the scope of user consent.
セクション1で説明したように、任意のサイトが呼び出しを開始できるようにすると、コアWebセキュリティ保証に違反します。ローカルデバイスへのアクセス制限がなければ、悪意のあるサイトは単にユーザーをバグにする可能性があります。したがって、少なくとも、任意のサイトがユーザーの同意なしに任意の場所への通話を開始することは不可能であってはなりません。しかし、これはすぐにユーザーの同意の範囲をどうすべきかという疑問を提起します。
In order for the user to make an intelligent decision about whether to allow a call (and hence their camera and microphone input to be routed somewhere), they must understand either who is requesting access, where the media is going, or both. As detailed below, there are two basic conceptual models:
ユーザーが通話を許可するかどうか（したがって、カメラとマイクの入力をどこかにルーティングするか）についてインテリジェントな決定を下すには、誰がアクセスを要求しているか、メディアがどこに行くか、またはその両方を理解する必要があります。以下に詳述するように、2つの基本的な概念モデルがあります。
1. You are sending your media to entity A because you want to talk to entity A (e.g., your mother).
1. エンティティA（母親など）と話したいので、メディアをエンティティAに送信しています。
2. Entity A (e.g., a calling service) asks to access the user's devices with the assurance that it will transfer the media to entity B (e.g., your mother).
2. エンティティA（例：通話サービス）は、メディアをエンティティB（例：母親）に転送することを保証して、ユーザーのデバイスにアクセスするように要求します。
In either case, identity is at the heart of any consent decision. Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C. Similarly, if you authorize A to place a call to B, A can call C instead. In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. The target of the media can of course advertise a security/privacy policy, but this is not something that the browser can enforce. Even so, there are a variety of different consent scenarios that motivate different technical consent mechanisms. We discuss these mechanisms in the sections below.
いずれの場合も、同意の決定の中心はアイデンティティです。さらに、ブラウザが接続しているパーティのIDは、ブラウザが意味のある形で強制できるすべてのものです。Aに電話をかけている場合、AはメディアをCに転送するだけです。同様に、AにBに電話をかけることを許可すると、Aは代わりにCに電話をかけることができます。いずれの場合も、ブラウザが実行できるのは、メディアの移動先を制御しているユーザーの認証を確認および確認することだけです。メディアのターゲットはもちろんセキュリティ/プライバシーポリシーを宣伝することができますが、これはブラウザが強制できるものではありません。それでも、さまざまな技術的同意メカニズムを動機付けるさまざまな同意シナリオがあります。これらのメカニズムについては、以下のセクションで説明します。
It's important to understand that consent to access local devices is largely orthogonal to consent to transmit various kinds of data over the network (see Section 4.2). Consent for device access is largely a matter of protecting the user's privacy from malicious sites. By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. Thus, we need to ensure communications consent even if the site is not able to access the camera and microphone at all (hence WebSockets's consent mechanism) and similarly, we need to be concerned with the site accessing the user's camera and microphone even if the data is to be sent back to the site via conventional HTTP-based network mechanisms such as HTTP POST.
ローカルデバイスにアクセスすることへの同意は、ネットワークを介してさまざまな種類のデータを送信することへの同意とほぼ直交していることを理解することが重要です（セクション4.2を参照）。デバイスアクセスへの同意は、主に悪意のあるサイトからユーザーのプライバシーを保護することです。対照的に、ネットワークトラフィックを送信することに同意するということは、ユーザーのブラウザがローカルネットワークを攻撃するために使用されるのを防ぐことです。したがって、サイトがカメラとマイクにまったくアクセスできない場合でも通信の同意を確保する必要があり（したがって、WebSocketsの同意メカニズム）、同様に、データがデータであっても、サイトがユーザーのカメラとマイクにアクセスすることに注意する必要があります。HTTPPOSTなどの従来のHTTPベースのネットワークメカニズムを介してサイトに送り返されます。
In addition to camera and microphone access, there has been demand for screen and/or application sharing functionality. Unfortunately, the security implications of this functionality are much harder for users to intuitively analyze than for camera and microphone access. (See <https://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html> for a full analysis.)
カメラとマイクへのアクセスに加えて、画面やアプリケーションの共有機能が求められています。残念ながら、この機能のセキュリティへの影響は、カメラやマイクへのアクセスよりも、ユーザーが直感的に分析するのがはるかに困難です。（完全な分析については、<https://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html>を参照してください。）
The most obvious threats are simply those of "oversharing". I.e., the user may believe they are sharing a window when in fact they are sharing an application, or may forget they are sharing their whole screen, icons, notifications, and all. This is already an issue with existing screen sharing technologies and is made somewhat worse if a partially trusted site is responsible for asking for the resource to be shared rather than having the user propose it.
最も明白な脅威は、単に「過剰共有」の脅威です。つまり、ユーザーは、実際にはアプリケーションを共有しているのにウィンドウを共有していると信じている場合や、画面全体、アイコン、通知などすべてを共有していることを忘れている場合があります。これは既存の画面共有テクノロジの問題であり、部分的に信頼されているサイトが、ユーザーに提案させるのではなく、リソースの共有を要求する責任がある場合は、さらに悪化します。
A less obvious threat involves the impact of screen sharing on the Web security model. A key part of the Same-Origin Policy is that HTML or JS from site A can reference content from site B and cause the browser to load it, but (unless explicitly permitted) cannot see the result. However, if a Web application from a site is screen sharing the browser, then this violates that invariant, with serious security consequences. For example, an attacker site might request screen sharing and then briefly open up a new window to the user's bank or webmail account, using screen sharing to read the resulting displayed content. A more sophisticated attack would be to open up a source view window to a site and use the screen sharing result to view anti-cross-site request forgery tokens.
それほど明白ではない脅威には、Webセキュリティモデルに対する画面共有の影響が含まれます。同一生成元ポリシーの重要な部分は、サイトAのHTMLまたはJSがサイトBのコンテンツを参照してブラウザにロードさせることができるが、（明示的に許可されていない限り）結果を表示できないことです。ただし、サイトのWebアプリケーションがブラウザを画面共有している場合、これはその不変条件に違反し、重大なセキュリティ上の影響を及ぼします。たとえば、攻撃者のサイトが画面共有を要求し、画面共有を使用して表示されたコンテンツを読み取ることにより、ユーザーの銀行またはWebメールアカウントに新しいウィンドウを短時間開く可能性があります。より高度な攻撃は、サイトへのソースビューウィンドウを開き、画面共有の結果を使用して、クロスサイトリクエストフォージェリトークンを表示することです。
These threats suggest that screen/application sharing might need a higher level of user consent than access to the camera or microphone.
これらの脅威は、画面/アプリケーションの共有には、カメラやマイクへのアクセスよりも高いレベルのユーザーの同意が必要になる可能性があることを示唆しています。
While a large number of possible calling scenarios are possible, the scenarios discussed in this section illustrate many of the difficulties of identifying the relevant scope of consent.
考えられる呼び出しシナリオは多数ありますが、このセクションで説明するシナリオは、関連する同意の範囲を特定することの難しさの多くを示しています。
The first scenario we consider is a dedicated calling service. In this case, the user has a relationship with a calling site and repeatedly makes calls on it. It is likely that rather than having to give permission for each call, the user will want to give the calling service long-term access to the camera and microphone. This is a natural fit for a long-term consent mechanism (e.g., installing an app store "application" to indicate permission for the calling service). A variant of the dedicated calling service is a gaming site (e.g., a poker site) which hosts a dedicated calling service to allow players to call each other.
私たちが考える最初のシナリオは、専用の通話サービスです。この場合、ユーザーは発信サイトと関係があり、繰り返し発信します。ユーザーは、通話ごとに許可を与えるのではなく、通話サービスにカメラとマイクへの長期アクセスを許可したいと思う可能性があります。これは、長期的な同意メカニズムに自然に適合します（たとえば、呼び出しサービスの許可を示すためにアプリストアの「アプリケーション」をインストールする）。専用通話サービスの変形は、プレーヤーが互いに電話をかけることを可能にする専用通話サービスをホストするゲームサイト（例えば、ポーカーサイト）である。
With any kind of service where the user may use the same service to talk to many different people, there is a question about whether the user can know who they are talking to. If I grant permission to calling service A to make calls on my behalf, then I am implicitly granting it permission to bug my computer whenever it wants. This suggests another consent model in which a site is authorized to make calls but only to certain target entities (identified via media-plane cryptographic mechanisms as described in Section 4.3.2 and especially Section 4.3.2.3). Note that the question of consent here is related to but distinct from the question of peer identity: I might be willing to allow a calling site to in general initiate calls on my behalf but still have some calls via that site where I can be sure that the site is not listening in.
ユーザーが同じサービスを使用して多くの異なる人々と話すことができるあらゆる種類のサービスでは、ユーザーが誰と話しているのかを知ることができるかどうかという疑問があります。サービスAに電話をかけて自分に代わって電話をかける許可を与えると、コンピューターにバグを報告する許可を暗黙的に与えます。これは、サイトが特定のターゲットエンティティに対してのみ呼び出しを行うことを許可されている別の同意モデルを示唆しています（セクション4.3.2、特にセクション4.3.2.3で説明されているメディアプレーン暗号化メカニズムを介して識別されます）。ここでの同意の問題は、ピアIDの問題に関連していますが、それとは異なることに注意してください。発信サイトが一般的に自分に代わって通話を開始できるようにすることをいとわないかもしれませんが、そのサイトを介していくつかの通話があり、サイトはリッスンしていません。
Another simple scenario is calling the site you're actually visiting. The paradigmatic case here is the "click here to talk to a representative" windows that appear on many shopping sites. In this case, the user's expectation is that they are calling the site they're actually visiting. However, it is unlikely that they want to provide a general consent to such a site; just because I want some information on a car doesn't mean that I want the car manufacturer to be able to activate my microphone whenever they please. Thus, this suggests the need for a second consent mechanism where I only grant consent for the duration of a given call. As described in Section 3.1, great care must be taken in the design of this interface to avoid the users just clicking through. Note also that the user interface chrome, which is the representation through which the user interacts with the user agent itself, must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely but shows a Web UI that implies otherwise.
もう1つの簡単なシナリオは、実際にアクセスしているサイトに電話をかけることです。ここでの典型的なケースは、多くのショッピングサイトに表示される「代表者と話すにはここをクリック」ウィンドウです。この場合、ユーザーの期待は、実際にアクセスしているサイトに電話をかけていることです。ただし、そのようなサイトに一般的な同意を提供することを望んでいる可能性はほとんどありません。車に関する情報が欲しいからといって、自動車メーカーがいつでもマイクをアクティブにできるようにしたいというわけではありません。したがって、これは、特定の通話の期間のみ同意を付与する2番目の同意メカニズムの必要性を示唆しています。セクション3.1で説明したように、ユーザーがクリックするだけにならないように、このインターフェイスの設計には細心の注意を払う必要があります。また、ユーザーがユーザーエージェント自体と対話するための表現であるユーザーインターフェイスchromeは、呼び出し元のサイトが無期限にそのままにしておく攻撃を回避するために、呼び出しが継続していることを示す要素を明確に表示する必要があることにも注意してください。それ以外のことを意味するWebUI。
Now that we have described the calling scenarios, we can start to reason about the security requirements.
呼び出しシナリオについて説明したので、セキュリティ要件について推論を開始できます。
As discussed in Section 3.2, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to the origin. Specifically, a script from origin A MUST only be allowed to initiate communications (and hence to access the camera and microphone) if the user has specifically authorized access for that origin. It is of course technically possible to have coarser-scoped permissions, but because the Web model is scoped to the origin, this creates a difficult mismatch.
セクション3.2で説明したように、Webサンドボックスの基本単位はオリジンであるため、オリジンにスコープ同意するのは自然なことです。具体的には、オリジンAからのスクリプトは、ユーザーがそのオリジンへのアクセスを特別に許可している場合にのみ、通信を開始すること（したがって、カメラとマイクにアクセスすること）を許可されなければなりません。もちろん、より粗いスコープのアクセス許可を持つことは技術的に可能ですが、Webモデルはオリジンにスコープされているため、これにより困難な不一致が発生します。
Arguably, the origin is not fine-grained enough. Consider the situation where Alice visits a site and authorizes it to make a single call. If consent is expressed solely in terms of the origin, then on any future visit to that site (including one induced via a mash-up or ad network), the site can bug Alice's computer, use the computer to place bogus calls, etc. While in principle Alice could grant and then revoke the privilege, in practice privileges accumulate; if we are concerned about this attack, something else is needed. There are a number of potential countermeasures to this sort of issue.
間違いなく、起源は十分にきめ細かいものではありません。アリスがサイトにアクセスし、1回の呼び出しを許可する状況を考えてみます。同意が発信元に関してのみ表明されている場合、そのサイトへの今後のアクセス（マッシュアップまたは広告ネットワークを介して誘導されたものを含む）で、サイトはアリスのコンピューターにバグを報告したり、コンピューターを使用して偽の電話をかけたりする可能性があります。原則として、アリスは特権を付与してから取り消すことができますが、実際には特権が蓄積されます。この攻撃が心配な場合は、別の何かが必要です。この種の問題には、いくつかの潜在的な対策があります。
Individual Consent Ask the user for permission for each call.
個別の同意各通話の許可をユーザーに求めます。
Callee-oriented Consent Only allow calls to a given user.
着信者指向の同意特定のユーザーへの通話のみを許可します。
Cryptographic Consent Only allow calls to a given set of peer keying material or to a cryptographically established identity.
暗号化同意特定のピアキーイングマテリアルのセットまたは暗号化されて確立されたIDへの呼び出しのみを許可します。
Unfortunately, none of these approaches is satisfactory for all cases. As discussed above, individual consent puts the user's approval in the UI flow for every call. Not only does this quickly become annoying but it can train the user to simply click "OK", at which point the consent becomes useless. Thus, while it may be necessary to have individual consent in some cases, this is not a suitable solution for (for instance) the calling service case. Where necessary, in-flow user interfaces must be carefully designed to avoid the risk of the user blindly clicking through.
残念ながら、これらのアプローチはすべての場合に満足できるものではありません。上で説明したように、個々の同意により、すべての呼び出しのUIフローでユーザーの承認が得られます。これはすぐに煩わしくなるだけでなく、「OK」をクリックするだけでユーザーをトレーニングすることができ、その時点で同意は役に立たなくなります。したがって、場合によっては個別の同意が必要になることもありますが、これは（たとえば）通話サービスの場合には適切な解決策ではありません。必要に応じて、ユーザーが盲目的にクリックスルーするリスクを回避するために、インフローユーザーインターフェイスを慎重に設計する必要があります。
The other two options are designed to restrict calls to a given target. Callee-oriented consent provided by the calling site would not work well because a malicious site can claim that the user is calling any user of their choice. One fix for this is to tie calls to a cryptographically established identity. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an IFRAME on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're still tying permissions to the origin here, but to the media origin (and/or destination) rather than to the Web origin. [RFC8827] describes mechanisms which facilitate this sort of consent.
他の2つのオプションは、特定のターゲットへの呼び出しを制限するように設計されています。悪意のあるサイトは、ユーザーが選択した任意のユーザーに電話をかけていると主張する可能性があるため、発信サイトが提供する着信者指向の同意はうまく機能しません。これに対する1つの修正は、暗号で確立されたIDに呼び出しを関連付けることです。すべての場合に適しているわけではありませんが、このアプローチは一部の場合に役立つ場合があります。広告の場合を考えると、許可を得るためだけにホスティングサイトでIFRAMEをインスタンス化するように広告主に要求することは特に便利ではありません。より便利なアプローチは、広告主の証明書を通信に直接暗号で結び付けることです。ここではまだオリジンにアクセス許可を結び付けていますが、Webオリジンではなくメディアオリジン（および/または宛先）にアクセス許可を結び付けています。[RFC8827]は、この種の同意を促進するメカニズムについて説明しています。
Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. If consent is tied to particular communications endpoints, then my risk is limited. Naturally, it is somewhat challenging to design UI primitives which express this sort of policy. The problem becomes even more challenging in multi-user calling cases.
メディアレベルの暗号化IDが理にかなっている別のケースは、ユーザーが呼び出し元のサイトを本当に信頼していない場合です。たとえば、通話サービスが私のコンピュータを盗聴しようとするのではないかと心配するかもしれませんが、友達に便利に電話をかけられるようにもしたいと思っています。同意が特定の通信エンドポイントに関連付けられている場合、私のリスクは制限されます。当然、この種のポリシーを表現するUIプリミティブを設計することはやや困難です。マルチユーザー通話の場合、この問題はさらに困難になります。
Origin-based security is intended to secure against Web attackers. However, we must also consider the case of network attackers. Consider the case where I have granted permission to a calling service by an origin that has the HTTP scheme, e.g., <http://calling-service.example.com>. If I ever use my computer on an unsecured network (e.g., a hotspot or if my own home wireless network is insecure), and browse any HTTP site, then an attacker can bug my computer. The attack proceeds like this:
オリジンベースのセキュリティは、Web攻撃者から保護することを目的としています。ただし、ネットワーク攻撃者の場合も考慮する必要があります。<http://calling-service.example.com>のように、HTTPスキームを持つオリジンによって呼び出しサービスに許可を与えた場合を考えてみます。安全でないネットワーク（ホットスポットや自宅のワイヤレスネットワークなど）でコンピューターを使用し、HTTPサイトを閲覧した場合、攻撃者はコンピューターにバグを報告する可能性があります。攻撃は次のように進行します。
1. I connect to <http://anything.example.org/>. Note that this site is unaffiliated with the calling service.
1. <http://anything.example.org/>に接続します。このサイトは通話サービスとは無関係であることに注意してください。
2. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to <http://calling-service.example.com>.
2. 攻撃者は私のHTTP接続を変更して、IFRAME（またはリダイレクト）を<http://calling-service.example.com>に挿入します。
3. The attacker forges the response from <http://calling-service.example.com/> to inject JS to initiate a call to themselves.
3. 攻撃者は<http://calling-service.example.com/>からの応答を偽造して、JSを挿入し、自分自身への呼び出しを開始します。
Note that this attack does not depend on the media being insecure. Because the call is to the attacker, it is also encrypted to them. Moreover, it need not be executed immediately; the attacker can "infect" the origin semi-permanently (e.g., with a Web worker or a popped-up window that is hidden under the main window) and thus be able to bug me long after I have left the infected network. This risk is created by allowing calls at all from a page fetched over HTTP.
この攻撃は、メディアが安全でないことに依存しないことに注意してください。呼び出しは攻撃者に対するものであるため、攻撃者に対しても暗号化されます。さらに、すぐに実行する必要はありません。攻撃者はオリジンを半永久的に「感染」させる可能性があり（たとえば、Webワーカーや、メインウィンドウの下に隠されたポップアップウィンドウを使用して）、感染したネットワークを離れてからずっと後にバグを報告する可能性があります。このリスクは、HTTPを介してフェッチされたページからの呼び出しをすべて許可することによって作成されます。
Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript is executed in the security context of the page [finer-grained]. This could lead to compromise of a call even if the parent page is safe. Note: This issue is not restricted to *pages* which contain untrusted content. If any page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi-permanently.
HTTPS [RFC2818]サイトからの呼び出しのみが可能であっても、それらのサイトに信頼できないサイトからのアクティブコンテンツ（JavaScriptなど）が含まれている場合、そのJavaScriptはページのセキュリティコンテキストで実行されます[きめ細かい]。これにより、親ページが安全であっても、通話が危険にさらされる可能性があります。注：この問題は、信頼できないコンテンツを含む*ページ*に限定されません。特定のオリジンのページが攻撃者からJavaScriptをロードした場合、その攻撃者がブラウザのそのオリジンの概念に半永久的に感染する可能性があります。
As discussed in Section 3.3, allowing Web applications unrestricted network access via the browser introduces the risk of using the browser as an attack platform against machines which would not otherwise be accessible to the malicious site, for instance, because they are topologically restricted (e.g., behind a firewall or NAT). In order to prevent this form of attack as well as cross-protocol attacks, it is important to require that the target of traffic explicitly consent to receiving the traffic in question. Until that consent has been verified for a given endpoint, traffic other than the consent handshake MUST NOT be sent to that endpoint.
セクション3.3で説明したように、ブラウザを介したWebアプリケーションの無制限のネットワークアクセスを許可すると、たとえば、トポロジ的に制限されているために、悪意のあるサイトにアクセスできないマシンに対する攻撃プラットフォームとしてブラウザを使用するリスクが生じます。ファイアウォールまたはNATの背後）。この形式の攻撃やクロスプロトコル攻撃を防ぐには、トラフィックのターゲットが問題のトラフィックの受信に明示的に同意することを要求することが重要です。特定のエンドポイントでその同意が確認されるまで、同意ハンドシェイク以外のトラフィックをそのエンドポイントに送信してはなりません（MUSTNOT）。
Note that consent verification is not sufficient to prevent overuse of network resources. Because WebRTC allows for a Web site to create data flows between two browser instances without user consent, it is possible for a malicious site to chew up a significant amount of a user's bandwidth without incurring significant costs to themselves by setting up such a channel to another user. However, as a practical matter there are a large number of Web sites which can act as data sources, so an attacker can at least use downlink bandwidth with existing Web APIs. However, this potential DoS vector reinforces the need for adequate congestion control for WebRTC protocols to ensure that they play fair with other demands on the user's bandwidth.
ネットワークリソースの過剰使用を防ぐには、同意の検証だけでは不十分であることに注意してください。WebRTCでは、Webサイトがユーザーの同意なしに2つのブラウザインスタンス間でデータフローを作成できるため、悪意のあるサイトが別のチャネルにそのようなチャネルを設定することで、ユーザーの帯域幅を大量に消費する可能性があります。ユーザー。ただし、実際問題として、データソースとして機能できるWebサイトは多数あるため、攻撃者は少なくとも既存のWebAPIでダウンリンク帯域幅を使用できます。ただし、この潜在的なDoSベクトルは、WebRTCプロトコルの適切な輻輳制御の必要性を強化し、ユーザーの帯域幅に対する他の要求と公平に連携できるようにします。
Verifying receiver consent requires some sort of explicit handshake, but conveniently we already need one in order to do NAT hole-punching. Interactive Connectivity Establishment (ICE) [RFC8445] includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender. It is important to remember here that the site initiating ICE is presumed malicious; in order for the handshake to be secure, the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (thus preventing the site from forging responses). In order to achieve this objective with ICE, the Session Traversal Utilities for NAT (STUN) transaction IDs must be generated by the browser and MUST NOT be made available to the initiating script, even via a diagnostic interface. Verifying receiver consent also requires verifying the receiver wants to receive traffic from a particular sender, and at this time; for example, a malicious site may simply attempt ICE to known servers that are using ICE for other sessions. ICE provides this verification as well, by using the STUN credentials as a form of per-session shared secret. Those credentials are known to the Web application, but would need to also be known and used by the STUN-receiving element to be useful.
受信者の同意を確認するには、ある種の明示的なハンドシェイクが必要ですが、NATホールパンチングを実行するには、すでにハンドシェイクが必要です。 Interactive Connectivity Establishment（ICE）[RFC8445]には、受信要素が送信者からのトラフィックの受信を希望していることを確認するように設計されたハンドシェイクが含まれています。ここで、ICEを開始するサイトは悪意があると推定されることを覚えておくことが重要です。ハンドシェイクを安全にするために、受信要素は、サイトで利用できない値の受信/知識を実証する必要があります（したがって、サイトが応答を偽造するのを防ぎます）。 ICEでこの目的を達成するには、NATのセッショントラバーサルユーティリティ（STUN）トランザクションIDをブラウザで生成する必要があり、診断インターフェイスを介しても、開始スクリプトで使用できるようにしてはなりません。受信者の同意を確認するには、受信者が特定の送信者からのトラフィックを受信することを望んでいることも確認する必要があります。たとえば、悪意のあるサイトが、他のセッションにICEを使用している既知のサーバーに対してICEを試行するだけの場合があります。 ICEは、セッションごとの共有秘密の形式としてSTUN資格情報を使用することにより、この検証も提供します。これらの資格情報はWebアプリケーションに認識されていますが、有用であるためには、STUN受信要素によっても認識および使用される必要があります。
There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it. Because ICE keepalives are indications, they will not work here. [RFC7675] describes the mechanism for providing consent freshness.
また、トラフィックのターゲットが引き続きトラフィックの受信を希望していることをブラウザが確認するための何らかのメカニズムが必要です。ICEキープアライブは兆候であるため、ここでは機能しません。[RFC7675]は、同意の鮮度を提供するためのメカニズムについて説明しています。
Once consent is verified, there still is some concern about misinterpretation attacks as described by Huang et al. [huang-w2sp]. This does not seem like it is of serious concern with DTLS because the ICE handshake enforces receiver consent and there is little evidence of passive DTLS proxies of the type studied by Huang. However, because RTCWEB can run over TCP there is some concern that attackers might control the ciphertext by controlling the plaintext input to SCTP. This risk is only partially mitigated by the fact that the SCTP stack controls the framing of the packets.
同意が確認された後も、Huang et al。によって説明されているように、誤解攻撃についての懸念がいくつかあります。[huang-w2sp]。ICEハンドシェイクは受信者の同意を強制し、Huangが調査したタイプのパッシブDTLSプロキシの証拠はほとんどないため、これはDTLSにとって深刻な懸念事項ではないようです。ただし、RTCWEBはTCPを介して実行できるため、攻撃者がSCTPへのプレーンテキスト入力を制御することによって暗号文を制御する可能性があるという懸念があります。このリスクは、SCTPスタックがパケットのフレーミングを制御するという事実によって部分的にのみ軽減されます。
Note that in principle an attacker could exert some control over Secure Real-time Transport Protocol (SRTP) packets by using a combination of the WebAudio API and extremely tight timing control. The primary risk here seems to be carriage of SRTP over Traversal Using Relays around NAT (TURN) TCP. However, as SRTP packets have an extremely characteristic packet header it seems unlikely that any but the most aggressive intermediaries would be confused into thinking that another application-layer protocol was in use.
原則として、攻撃者はWebAudio APIと非常に厳密なタイミング制御の組み合わせを使用して、Secure Real-time Transport Protocol（SRTP）パケットをある程度制御できることに注意してください。ここでの主なリスクは、NAT（TURN）TCP周辺のリレーを使用したトラバーサルを介したSRTPの伝送であるようです。ただし、SRTPパケットには非常に特徴的なパケットヘッダーがあるため、最も攻撃的な仲介者以外が、別のアプリケーション層プロトコルが使用されていると誤解する可能性はほとんどありません。
| Note: The RTCWEB WG ultimately decided to require ICE. This | section provides context for that decision.
A requirement to use ICE limits compatibility with legacy non-ICE clients. It seems unsafe to completely remove the requirement for some check. All proposed checks have the common feature that the browser sends some message to the candidate traffic recipient and refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE candidates for this role (in cases where the legacy endpoint has a public address) include:
ICEを使用するための要件により、従来の非ICEクライアントとの互換性が制限されます。一部のチェックの要件を完全に削除することは安全ではないようです。提案されたすべてのチェックには、ブラウザがトラフィック受信者候補にメッセージを送信し、そのメッセージが返信されるまで他のトラフィックの送信を拒否するという共通の機能があります。メッセージ/応答ペアは、Webアプリケーションを制御する攻撃者がそれらを偽造できないように生成する必要があります。通常、メッセージに組み込む必要のある秘密の値（エコー、ハッシュなど）を含めることによって作成します。この役割のICE以外の候補（レガシーエンドポイントにパブリックアドレスがある場合）には、次のものがあります。
* STUN checks without using ICE (i.e., the non-RTC-web endpoint sets up a STUN responder).
* STUNはICEを使用せずにチェックします（つまり、RTC以外のWebエンドポイントがSTUNレスポンダーをセットアップします）。
* Use of the RTP Control Protocol (RTCP) as an implicit reachability check.
* 暗黙の到達可能性チェックとしてのRTP制御プロトコル（RTCP）の使用。
In the RTCP approach, the WebRTC endpoint is allowed to send a limited number of RTP packets prior to receiving consent. This allows a short window of attack. In addition, some legacy endpoints do not support RTCP, so this is a much more expensive solution for such endpoints, for which it would likely be easier to implement ICE. For these two reasons, an RTCP-based approach does not seem to address the security issue satisfactorily.
RTCPアプローチでは、WebRTCエンドポイントは、同意を受け取る前に、限られた数のRTPパケットを送信できます。これにより、攻撃の短いウィンドウが可能になります。さらに、一部のレガシーエンドポイントはRTCPをサポートしていないため、これはそのようなエンドポイントにとってはるかに高価なソリューションであり、ICEの実装がより簡単になる可能性があります。これら2つの理由から、RTCPベースのアプローチではセキュリティの問題に十分に対処できないようです。
In the STUN approach, the WebRTC endpoint is able to verify that the recipient is running some kind of STUN endpoint but unless the STUN responder is integrated with the ICE username/password establishment system, the WebRTC endpoint cannot verify that the recipient consents to this particular call. This may be an issue if existing STUN servers are operated at addresses that are not able to handle bandwidth-based attacks. Thus, this approach does not seem satisfactory either.
STUNアプローチでは、WebRTCエンドポイントは受信者が何らかのSTUNエンドポイントを実行していることを確認できますが、STUNレスポンダーがICEユーザー名/パスワード確立システムと統合されていない限り、WebRTCエンドポイントは受信者がこの特定のことに同意していることを確認できません。コール。これは、既存のSTUNサーバーが帯域幅ベースの攻撃を処理できないアドレスで運用されている場合に問題になる可能性があります。したがって、このアプローチも満足のいくものではないようです。
If the systems are tightly integrated (i.e., the STUN endpoint responds with responses authenticated with ICE credentials), then this issue does not exist. However, such a design is very close to an ICE-Lite implementation (indeed, arguably is one). An intermediate approach would be to have a STUN extension that indicated that one was responding to WebRTC checks but not computing integrity checks based on the ICE credentials. This would allow the use of standalone STUN servers without the risk of confusing them with legacy STUN servers. If a non-ICE legacy solution is needed, then this is probably the best choice.
システムが緊密に統合されている場合（つまり、STUNエンドポイントがICE資格情報で認証された応答で応答する場合）、この問題は存在しません。ただし、このような設計はICE-Liteの実装に非常に近いものです（実際、間違いなく1つです）。中間的なアプローチは、WebRTCチェックに応答しているが、ICE資格情報に基づいて整合性チェックを計算していないことを示すSTUN拡張機能を使用することです。これにより、従来のSTUNサーバーと混同するリスクなしにスタンドアロンのSTUNサーバーを使用できるようになります。ICE以外のレガシーソリューションが必要な場合は、これがおそらく最良の選択です。
Once initial consent is verified, we also need to verify continuing consent, in order to avoid attacks where two people briefly share an IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges for a large, unstoppable, traffic flow to the network and then leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats are less severe.
最初の同意が確認されたら、継続的な同意も確認する必要があります。これは、2人が一時的にIPを共有し（インターネットカフェのNATの背後など）、攻撃者が大規模で停止できないトラフィックフローを手配する攻撃を回避するためです。ネットワークを離れてから去ります。ここでの適切な技術は、最初の同意の技術とかなり似ていますが、脅威はそれほど深刻ではないため、おそらく弱いです。
Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server-reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. In addition, either side may wish to hide their location from the other side entirely by forcing all traffic through a TURN server.
呼び出し先がICE候補を送信するとすぐに、呼び出し元は呼び出し先のIPアドレスを学習することに注意してください。呼び出し先のサーバー再帰アドレスは、呼び出し先の場所に関する多くの情報を明らかにします。追跡を回避するために、実装は、呼び出し先が応答するまでICEネゴシエーションの開始を抑制したい場合があります。さらに、どちらの側も、すべてのトラフィックをTURNサーバーに強制的に通すことにより、反対側から自分の場所を完全に隠したい場合があります。
In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor <https://www.torproject.org> or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. See [RFC8828] for additional information.
通常の操作では、サイトはブラウザのIPアドレスを学習しますが、Tor <https://www.torproject.org>やVPNなどのメカニズムを介して非表示になっている場合があります。ただし、サイトはブラウザにIPアドレスを提供させる可能性があるため、ユーザーがIPアドレスをマスクするVPNの背後にいる場合でも、サイトがユーザーのネットワーク環境について学習するメカニズムを提供します。実装では、ユーザーが特定の種類のVPN、特にTorなどのプライバシー指向のシステムを使用している場合に、VPN以外のすべての候補を抑制する設定を提供したい場合があります。詳細については、[RFC8828]を参照してください。
Finally, we consider a problem familiar from the SIP world: communications security. For obvious reasons, it MUST be possible for the communicating parties to establish a channel which is secure against both message recovery and message modification. (See [RFC5479] for more details.) This service must be provided for both data and voice/video. Ideally the same security mechanisms would be used for both types of content. Technology for providing this service (for instance, SRTP [RFC3711], DTLS [RFC6347], and DTLS-SRTP [RFC5763]) is well understood. However, we must examine this technology in the WebRTC context, where the threat model is somewhat different.
最後に、SIPの世界でよく知られている問題である通信セキュリティについて考察します。明らかな理由で、通信する当事者がメッセージの回復とメッセージの変更の両方に対して安全なチャネルを確立することが可能でなければなりません。（詳細については、[RFC5479]を参照してください。）このサービスは、データと音声/ビデオの両方に提供する必要があります。理想的には、同じセキュリティメカニズムが両方のタイプのコンテンツに使用されます。このサービスを提供するためのテクノロジー（たとえば、SRTP [RFC3711]、DTLS [RFC6347]、およびDTLS-SRTP [RFC5763]）はよく理解されています。ただし、脅威モデルが多少異なるWebRTCコンテキストでこのテクノロジーを検討する必要があります。
In general, it is important to understand that unlike a conventional SIP proxy, the calling service (i.e., the Web server) controls not only the channel between the communicating endpoints but also the application running on the user's browser. While in principle it is possible for the browser to cut the calling service out of the loop and directly present trusted information (and perhaps get consent), practice in modern browsers is to avoid this whenever possible. "In-flow" modal dialogs which require the user to consent to specific actions are particularly disfavored as human factors research indicates that unless they are made extremely invasive, users simply agree to them without actually consciously giving consent [abarth-rtcweb]. Thus, nearly all the UI will necessarily be rendered by the browser but under control of the calling service. This likely includes the peer's identity information, which, after all, is only meaningful in the context of some calling service.
一般に、従来のSIPプロキシとは異なり、呼び出し元サービス（つまり、Webサーバー）は、通信するエンドポイント間のチャネルだけでなく、ユーザーのブラウザーで実行されているアプリケーションも制御することを理解することが重要です。原則として、ブラウザーが呼び出しサービスをループから切り離し、信頼できる情報を直接提示する（そしておそらく同意を得る）ことは可能ですが、最近のブラウザーでの実践は、可能な限りこれを回避することです。ユーザーが特定のアクションに同意する必要がある「インフロー」モーダルダイアログは、ヒューマンファクターの調査によると、極端に侵襲的にならない限り、ユーザーは実際に意識的に同意することなく単に同意するだけであることが示されているため、特に嫌われています[abarth-rtcweb]。したがって、ほぼすべてのUIは必然的にブラウザーによってレンダリングされますが、呼び出し元サービスの制御下にあります。これには、ピアのID情報が含まれている可能性があります。これは、結局のところ、一部の呼び出しサービスのコンテキストでのみ意味があります。
This limitation does not mean that preventing attack by the calling service is completely hopeless. However, we need to distinguish between two classes of attack:
この制限は、呼び出しサービスによる攻撃を防ぐことが完全に絶望的であることを意味するものではありません。ただし、次の2つのクラスの攻撃を区別する必要があります。
Retrospective compromise of calling service: The calling service is non-malicious during a call but subsequently is compromised and wishes to attack an older call (often called a "passive attack").
通話サービスの遡及的侵害：通話中は悪意のない通話サービスですが、その後侵害され、古い通話を攻撃したいと考えています（「受動的攻撃」と呼ばれることがよくあります）。
During-call attack by calling service: The calling service is compromised during the call it wishes to attack (often called an "active attack").
通話サービスによる通話中の攻撃：通話サービスは、攻撃したい通話中に侵害されます（「アクティブ攻撃」と呼ばれることがよくあります）。
Providing security against the former type of attack is practical using the techniques discussed in Section 4.3.1. However, it is extremely difficult to prevent a trusted but malicious calling service from actively attacking a user's calls, either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note that this attack applies equally to a network attacker if communications to the calling service are not secured.) We discuss some potential approaches in Section 4.3.2.
前者のタイプの攻撃に対するセキュリティを提供することは、セクション4.3.1で説明した手法を使用して実用的です。ただし、Man-in-the-Middle（MITM）攻撃を仕掛けるか、完全に迂回させることによって、信頼できるが悪意のある通話サービスがユーザーの通話を積極的に攻撃するのを防ぐことは非常に困難です。（この攻撃は、呼び出し元サービスへの通信が保護されていない場合、ネットワーク攻撃者にも同様に適用されることに注意してください。）セクション4.3.2で、いくつかの潜在的なアプローチについて説明します。
In a retrospective attack, the calling service was uncompromised during the call, but an attacker subsequently wants to recover the content of the call. We assume that the attacker has access to the protected media stream as well as full control of the calling service.
遡及的攻撃では、通話中に通話サービスは危険にさらされませんでしたが、攻撃者はその後、通話の内容を回復したいと考えています。攻撃者は、保護されたメディアストリームにアクセスできるだけでなく、呼び出し元サービスを完全に制御できると想定しています。
If the calling service has access to the traffic keying material (as in Security Descriptions (SDES) [RFC4568]), then retrospective attack is trivial. This form of attack is particularly serious in the Web context because it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly likely that if the traffic key is part of any HTTP request it will be logged somewhere and thus subject to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system), and this mechanism SHOULD provide Forward Secrecy (FS). The signaling channel/calling service can be used to authenticate this mechanism.
呼び出し側サービスがトラフィックキーイングマテリアルにアクセスできる場合（セキュリティ記述（SDES）[RFC4568]のように）、遡及的攻撃は簡単です。この形式の攻撃は、Webサービスでは広範なロギングと監視を実行することが標準的な方法であるため、Webコンテキストでは特に深刻です。したがって、トラフィックキーがHTTPリクエストの一部である場合、どこかにログが記録され、その後の侵害の対象となる可能性が高くなります。WebRTCに自動の公開鍵ベースの鍵交換メカニズムを必須にするのはこの考慮事項であり（これはあらゆる通信セキュリティシステムにとって良い考えです）、このメカニズムはForward Secrecy（FS）を提供する必要があります。シグナリングチャネル/呼び出しサービスを使用して、このメカニズムを認証できます。
In addition, if end-to-end keying is used, the system MUST NOT provide any APIs to either extract long-term keying material or to directly access any stored traffic keys. Otherwise, an attacker who subsequently compromised the calling service might be able to use those APIs to recover the traffic keys and thus compromise the traffic.
さらに、エンドツーエンドのキーイングを使用する場合、システムは、長期のキーイングマテリアルを抽出したり、保存されているトラフィックキーに直接アクセスしたりするためのAPIを提供してはなりません（MUSTNOT）。そうしないと、後で呼び出しサービスを侵害した攻撃者が、これらのAPIを使用してトラフィックキーを回復し、トラフィックを侵害する可能性があります。
Protecting against attacks during a call is a more difficult proposition. Even if the calling service cannot directly access keying material (as recommended in the previous section), it can simply mount a man-in-the-middle attack on the connection, telling Alice that she is calling Bob and Bob that he is calling Alice, while in fact the calling service is acting as a calling bridge and capturing all the traffic. Protecting against this form of attack requires positive authentication of the remote endpoint such as explicit out-of-band key verification (e.g., by a fingerprint) or a third-party identity service as described in [RFC8827].
通話中の攻撃から保護することは、より難しい提案です。呼び出しサービスがキー情報に直接アクセスできない場合でも（前のセクションで推奨されているように）、接続に中間者攻撃を仕掛け、アリスにボブに電話していることとボブに電話していることを伝えることができます。、実際には、呼び出しサービスは呼び出しブリッジとして機能し、すべてのトラフィックをキャプチャしています。この形式の攻撃から保護するには、[RFC8827]で説明されているように、明示的な帯域外キー検証（指紋などによる）やサードパーティのIDサービスなどのリモートエンドポイントの確実な認証が必要です。
One natural approach is to use "key continuity". While a malicious calling service can present any identity it chooses to the user, it cannot produce a private key that maps to a given public key. Thus, it is possible for the browser to note a given user's public key and generate an alarm whenever that user's key changes. The Secure Shell (SSH) protocol [RFC4251] uses a similar technique. (Note that the need to avoid explicit user consent on every call precludes the browser requiring an immediate manual check of the peer's key.)
自然なアプローチの1つは、「キーの継続性」を使用することです。悪意のある呼び出しサービスは、選択したIDをユーザーに提示できますが、特定の公開鍵にマップする秘密鍵を生成することはできません。したがって、ブラウザは特定のユーザーの公開鍵を記録し、そのユーザーの鍵が変更されるたびにアラームを生成することができます。セキュアシェル（SSH）プロトコル[RFC4251]も同様の手法を使用しています。（すべての呼び出しでユーザーの明示的な同意を回避する必要があるため、ブラウザーはピアのキーをすぐに手動でチェックする必要がないことに注意してください。）
Unfortunately, this sort of key continuity mechanism is far less useful in the WebRTC context. First, much of the virtue of WebRTC (and any Web application) is that it is not bound to a particular piece of client software. Thus, it will be not only possible but routine for a user to use multiple browsers on different computers that will of course have different keying material (Securely Available Credentials (SACRED) [RFC3760] notwithstanding). Thus, users will frequently be alerted to key mismatches which are in fact completely legitimate, with the result that they are trained to simply click through them. As it is known that users routinely will click through far more dire warnings [cranor-wolf], it seems extremely unlikely that any key continuity mechanism will be effective rather than simply annoying.
残念ながら、この種のキー継続性メカニズムは、WebRTCコンテキストではあまり役に立ちません。まず、WebRTC（および任意のWebアプリケーション）の利点の多くは、特定のクライアントソフトウェアにバインドされていないことです。したがって、ユーザーが異なるコンピューター上で複数のブラウザーを使用することは可能であるだけでなく、ルーチンであり、もちろん異なるキー情報があります（Securely Available Credentials（SACRED）[RFC3760]にもかかわらず）。したがって、ユーザーは、実際には完全に正当なキーの不一致について頻繁に警告を受け、その結果、ユーザーは単にクリックするように訓練されます。ユーザーが日常的にはるかに多くの悲惨な警告[cranor-wolf]をクリックすることが知られているので、キー継続メカニズムが単に煩わしいというよりも効果的である可能性は非常に低いようです。
Moreover, it is trivial to bypass even this kind of mechanism. Recall that unlike the case of SSH, the browser never directly gets the peer's identity from the user. Rather, it is provided by the calling service. Even enabling a mechanism of this type would require an API to allow the calling service to tell the browser "this is a call to user X." All the calling service needs to do to avoid triggering a key continuity warning is to tell the browser that "this is a call to user Y" where Y is confusable with X. Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to use the trusted UI to provide the name and (b) the user to not be fooled by similar appearing names.
さらに、この種のメカニズムでさえバイパスすることは簡単です。SSHの場合とは異なり、ブラウザがユーザーからピアのIDを直接取得することは決してないことを思い出してください。むしろ、それは呼び出しサービスによって提供されます。このタイプのメカニズムを有効にする場合でも、呼び出し元のサービスがブラウザーに「これはユーザーXへの呼び出しです」と通知できるようにするAPIが必要になります。キー継続性警告のトリガーを回避するために呼び出すサービスは、「これはユーザーYへの呼び出しです」とブラウザに通知するだけです。YはXと混同されます。ユーザーが実際に相手の名前を確認した場合でも（すべて利用可能）証拠が示す可能性は低いです）、これには、（a）ブラウザが信頼できるUIを使用して名前を提供し、（b）ユーザーが同様の名前にだまされないようにする必要があります。
ZRTP [RFC6189] uses a "Short Authentication String" (SAS) which is derived from the key agreement protocol. This SAS is designed to be compared by the users (e.g., read aloud over the voice channel or transmitted via an out-of-band channel) and if confirmed by both sides precludes MITM attack. The intention is that the SAS is used once and then key continuity (though with a different mechanism from that discussed above) is used thereafter.
ZRTP [RFC6189]は、鍵共有プロトコルから派生した「Short AuthenticationString」（SAS）を使用します。このSASは、ユーザーが比較するように設計されており（たとえば、音声チャネルを介して読み上げたり、帯域外チャネルを介して送信したり）、両側で確認された場合、MITM攻撃を排除します。その意図は、SASが一度使用され、その後、キーの継続性（ただし、上記で説明したメカニズムとは異なるメカニズム）が使用されることです。
Unfortunately, the SAS does not offer a practical solution to the problem of a compromised calling service. "Voice cloning" systems, which mimic the voice of a given speaker are an active area of research [deepfakes-ftc] and are already being used in real-world attacks [deepfakes-fraud]. These attacks are likely to improve in future, especially in an environment where the user just wants to get on with the phone call. Thus, even if the SAS is effective today, it is likely not to be so for much longer.
残念ながら、SASは、通話サービスの侵害の問題に対する実用的な解決策を提供していません。特定の話者の声を模倣する「音声クローニング」システムは、活発な研究分野であり[deepfakes-ftc]、すでに実際の攻撃で使用されています[deepfakes-fraud]。これらの攻撃は、特にユーザーが電話をかけたいだけの環境では、将来的に改善される可能性があります。したがって、SASが今日有効であったとしても、それほど長くはない可能性があります。
Additionally, it is unclear that users will actually use an SAS. As discussed above, the browser UI constraints preclude requiring the SAS exchange prior to completing the call and so it must be voluntary; at most the browser will provide some UI indicator that the SAS has not yet been checked. However, it is well known that when faced with optional security mechanisms, many users simply ignore them [whitten-johnny].
さらに、ユーザーが実際にSASを使用するかどうかは不明です。上で説明したように、ブラウザのUIの制約により、呼び出しを完了する前にSAS交換を要求することはできないため、任意である必要があります。せいぜいブラウザは、SASがまだチェックされていないことを示すUIインジケータを提供します。ただし、オプションのセキュリティメカニズムに直面した場合、多くのユーザーは単にそれらを無視することはよく知られています[whitten-johnny]。
Once users have checked the SAS once, key continuity is required to avoid them needing to check it on every call. However, this is problematic for reasons indicated in Section 4.3.2.1. In principle it is of course possible to render a different UI element to indicate that calls are using an unauthenticated set of keying material (recall that the attacker can just present a slightly different name so that the attack shows the same UI as a call to a new device or to someone you haven't called before), but as a practical matter, users simply ignore such indicators even in the rather more dire case of mixed content warnings.
ユーザーがSASを一度チェックすると、すべての呼び出しでSASをチェックする必要がないように、キーの継続性が必要になります。ただし、これはセクション4.3.2.1に示されている理由により問題があります。原則として、異なるUI要素をレンダリングして、呼び出しが認証されていないキーマテリアルのセットを使用していることを示すことはもちろん可能です（攻撃者がわずかに異なる名前を提示して、攻撃が呼び出しと同じUIを表示できることを思い出してください。新しいデバイスまたは以前に電話をかけたことのない人に）が、実際問題として、ユーザーは、混合コンテンツの警告のかなり悲惨な場合でも、そのようなインジケーターを単に無視します。
The conventional approach to providing communications identity has of course been to have some third-party identity system (e.g., PKI) to authenticate the endpoints. Such mechanisms have proven to be too cumbersome for use by typical users (and nearly too cumbersome for administrators). However, a new generation of Web-based identity providers (BrowserID, Federated Google Login, Facebook Connect, OAuth [RFC6749], OpenID [OpenID], WebFinger [RFC7033]) has been developed and use Web technologies to provide lightweight (from the user's perspective) third-party authenticated transactions. It is possible to use systems of this type to authenticate WebRTC calls, linking them to existing user notions of identity (e.g., Facebook adjacencies). Specifically, the third-party identity system is used to bind the user's identity to cryptographic keying material which is then used to authenticate the calling endpoints. Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site.
もちろん、通信IDを提供するための従来のアプローチは、エンドポイントを認証するためのサードパーティIDシステム（PKIなど）を使用することでした。このようなメカニズムは、一般的なユーザーが使用するには面倒すぎることが証明されています（管理者にとっては面倒です）。ただし、新世代のWebベースのIDプロバイダー（BrowserID、Federated Google Login、Facebook Connect、OAuth [RFC6749]、OpenID [OpenID]、WebFinger [RFC7033]）が開発され、Webテクノロジーを使用して軽量化を実現しています（ユーザーのパースペクティブ）サードパーティの認証済みトランザクション。このタイプのシステムを使用してWebRTC呼び出しを認証し、それらを既存のユーザーのID概念（Facebookの隣接関係など）にリンクすることができます。具体的には、サードパーティのIDシステムを使用して、ユーザーのIDを暗号化キーイングマテリアルにバインドし、暗号化キーイングマテリアルを使用して呼び出し側エンドポイントを認証します。この方法で認証された通話は、発信サイトによるアクティブなMITM攻撃に対しても当然耐性があります。
Note that there is one special case in which PKI-style certificates do provide a practical solution: calls from end users to large sites. For instance, if you are making a call to Amazon.com, then Amazon can easily get a certificate to authenticate their media traffic, just as they get one to authenticate their Web traffic. This does not provide additional security value in cases in which the calling site and the media peer are one and the same, but might be useful in cases in which third parties (e.g., ad networks or retailers) arrange for calls but do not participate in them.
PKIスタイルの証明書が実用的なソリューションを提供する特別なケースが1つあることに注意してください。それは、エンドユーザーから大規模サイトへの呼び出しです。たとえば、Amazon.comに電話をかける場合、Amazonは、Webトラフィックを認証するための証明書を取得するのと同じように、メディアトラフィックを認証するための証明書を簡単に取得できます。これは、発信サイトとメディアピアが同一である場合には追加のセキュリティ値を提供しませんが、サードパーティ（広告ネットワークや小売業者など）が通話を手配するが参加しない場合には役立つ可能性があります。それら。
Identifying the identity of the far media endpoint is a necessary but not sufficient condition for providing media security. In WebRTC, media flows are rendered into HTML5 MediaStreams which can be manipulated by the calling site. Obviously, if the site can modify or view the media, then the user is not getting the level of assurance they would expect from being able to authenticate their peer. In many cases, this is acceptable because the user values site-based special effects over complete security from the site. However, there are also cases where users wish to know that the site cannot interfere. In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams. This verification must be possible both from the local side and the remote side. I.e., users must be able to verify that the person called has engaged a secure media mode (see Section 4.3.3). In order to achieve this, it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections.
ファーメディアエンドポイントのIDを特定することは必要ですが、メディアセキュリティを提供するための十分条件ではありません。 WebRTCでは、メディアフローはHTML5 MediaStreamsにレンダリングされ、呼び出し元のサイトで操作できます。明らかに、サイトがメディアを変更または表示できる場合、ユーザーはピアを認証できることから期待されるレベルの保証を得ていません。多くの場合、ユーザーはサイトからの完全なセキュリティよりもサイトベースの特殊効果を重視するため、これは許容されます。ただし、ユーザーがサイトが干渉できないことを知りたい場合もあります。それを容易にするために、サイトがメディアストリームへのアクセスを検証可能に放棄できる機能を提供する必要があります。この検証は、ローカル側とリモート側の両方で可能である必要があります。つまり、ユーザーは、呼び出された人がセキュアメディアモードを使用していることを確認できる必要があります（セクション4.3.3を参照）。これを実現するには、ローカルメディアアクセスポリシーの表示を、前のセクションで説明した暗号化認証手順に暗号化してバインドする必要があります。
It should be noted that the use of this secure media mode is left to the discretion of the site. When such a mode is engaged, the browser will need to provide indicia to the user that the associated media has been authenticated as coming from the identified user. This allows WebRTC services that wish to claim end-to-end security to do so in a way that can be easily verified by the user. This model requires that the remote party's browser be included in the TCB, as described in Section 3.
このセキュアメディアモードの使用は、サイトの裁量に任されていることに注意してください。このようなモードが有効になっている場合、ブラウザは、関連付けられたメディアが識別されたユーザーからのものであると認証されたことをユーザーに示す必要があります。これにより、エンドツーエンドのセキュリティを要求するWebRTCサービスは、ユーザーが簡単に確認できる方法で要求することができます。このモデルでは、セクション3で説明されているように、リモートパーティのブラウザがTCBに含まれている必要があります。
One class of attack that we do not generally try to prevent is malicious peers. For instance, no matter what confidentiality measures you employ the person you are talking to might record the call and publish it on the Internet. Similarly, we do not attempt to prevent them from using voice or video processing technology for hiding or changing their appearance. While technologies (Digital Rights Management (DRM), etc.) do exist to attempt to address these issues, they are generally not compatible with open systems and WebRTC does not address them.
一般的に防止しようとしない攻撃の1つのクラスは、悪意のあるピアです。たとえば、話している相手をどのような機密保持手段で採用しても、通話を録音してインターネットに公開する場合があります。同様に、私たちは、彼らが彼らの外見を隠したり変更したりするために音声またはビデオ処理技術を使用することを妨げようとはしません。これらの問題に対処しようとするテクノロジー（デジタル著作権管理（DRM）など）は存在しますが、一般にオープンシステムと互換性がなく、WebRTCはそれらに対処しません。
Similarly, we make no attempt to prevent prank calling or other unwanted calls. In general, this is in the scope of the calling site, though because WebRTC does offer some forms of strong authentication, that may be useful as part of a defense against such attacks.
同様に、いたずら電話やその他の不要な電話を防止しようとはしていません。一般に、これは呼び出し元サイトの範囲内ですが、WebRTCは何らかの形式の強力な認証を提供するため、このような攻撃に対する防御の一部として役立つ場合があります。
While persistent endpoint identifiers can be a useful security feature (see Section 4.3.2.1), they can also represent a privacy threat in settings where the user wishes to be anonymous. WebRTC provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMEs (if generated according to [RFC6222] rather than the privacy-preserving mode of [RFC7022]). In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies). Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers. In addition, IP addresses can be a source of call linkage [RFC8828].
永続的なエンドポイント識別子は便利なセキュリティ機能ですが（セクション4.3.2.1を参照）、ユーザーが匿名を希望する設定ではプライバシーの脅威を表すこともあります。WebRTCは、DTLS証明書（接続間で再利用される場合）やRTCP CNAME（[RFC7022]のプライバシー保護モードではなく[RFC6222]に従って生成される場合）など、いくつかの可能な永続識別子を提供します。このタイプの相関関係を防ぐために、ブラウザはこれらの識別子をリセットするメカニズムを提供する必要があります（たとえば、Cookieと同じ存続期間）。さらに、APIは、匿名呼び出しを目的としたサイトが新しい識別子の作成を強制できるようにするメカニズムを提供する必要があります。さらに、IPアドレスはコールリンケージのソースになる可能性があります[RFC8828]。
Any new set of API features adds a risk of browser fingerprinting, and WebRTC is no exception. Specifically, sites can use the presence or absence of specific devices as a browser fingerprint. In general, the API needs to be balanced between functionality and the incremental fingerprint risk. See [Fingerprinting].
API機能の新しいセットは、ブラウザーのフィンガープリントのリスクを追加します。WebRTCも例外ではありません。具体的には、サイトは特定のデバイスの有無をブラウザのフィンガープリントとして使用できます。一般に、APIは、機能と増分指紋リスクの間でバランスを取る必要があります。[指紋]を参照してください。
This entire document is about security.
このドキュメント全体はセキュリティに関するものです。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードにおける大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/rfc8174>。
[abarth-rtcweb] Barth, A., "Prompting the user is security failure", RTC-Web Workshop, September 2010, <http://rtc-web.alvestrand.com/home/papers/barth-security-prompt.pdf?attredirects=0>.
[abarth-rtcweb] Barth、A。、「ユーザーへのプロンプトはセキュリティ障害です」、RTC-Web Workshop、2010年9月、<http://rtc-web.alvestrand.com/home/papers/barth-security-prompt。pdf？attredirects = 0>。
[cranor-wolf] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", Proceedings of the 18th USENIX Security Symposium, August 2009, <https://www.usenix.org/legacy/event/sec09/tech/ full_papers/sunshine.pdf>.
[cranor-wolf] Sunshine、J.、Egelman、S.、Almuhimedi、H.、Atri、N。、およびL. Cranor、「Crying Wolf：SSL警告の有効性に関する実証的研究」、第18回USENIXセキュリティシンポジウムの議事録、2009年8月、<https://www.usenix.org/legacy/event/sec09/tech/full_papers/sunshine.pdf>。
[deepfakes-fraud] Statt, N., "Thieves are now using AI deepfakes to trick companies into sending them money", September 2019, <https://www.theverge.com/2019/9/5/20851248/deepfakes-ai-fake-audio-phone-calls-thieves-trick-companies-stealing-money>.
[deepfakes-fraud] Statt、N。、「泥棒は現在AIディープフェイクを使用して、企業をだまして送金させています」、2019年9月、<https://www.theverge.com/2019/9/5/20851248/deepfakes-ai-fake-audio-phone-calls-thieves-trick-companies-stealing-money>。
[deepfakes-ftc] Lyons, K., "FTC says the tech behind audio deepfakes is getting better", January 2020, <https://www.theverge.com/2020/1/29/21080553/ftc-deepfakes-audio-cloning-joe-rogan-phone-scams>.
[deepfakes-ftc] Lyons、K。、「FTCによると、オーディオディープフェイクの背後にある技術は向上している」、2020年1月、<https://www.theverge.com/2020/1/29/21080553/ftc-deepfakes-audio-cloning-joe-rogan-phone-scams>。
[fetch] van Kesteren, A., "Fetch", <https://fetch.spec.whatwg.org/>.
[フェッチ] van Kesteren、A。、「Fetch」、<https://fetch.spec.whatwg.org/>。
[finer-grained] Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", Web 2.0 Security and Privacy (W2SP 2008), July 2008.
[きめ細かい] Jackson、C。and A. Barth、 "Beware of Finer-Grained Origins"、Web 2.0 Security and Privacy（W2SP 2008）、2008年7月。
[Fingerprinting] Doty, N., Ed., "Mitigating Browser Fingerprinting in Web Specifications", March 2019, <https://www.w3.org/TR/fingerprinting-guidance/>.
[フィンガープリント] Doty、N.、Ed。、「Web仕様におけるブラウザフィンガープリントの軽減」、2019年3月、<https://www.w3.org/TR/fingerprinting-guidance/>。
[huang-w2sp] Huang, L-S., Chen, E.Y., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", Web 2.0 Security and Privacy (W2SP 2011), May 2011.
[huang-w2sp] Huang、LS。、Chen、EY、Barth、A.、Rescorla、E。、およびC. Jackson、「Talking to Yourself for Fun and Profit」、Web 2.0セキュリティとプライバシー（W2SP 2011）、5月2011年。
[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID] Sakimura、N.、Bradley、J.、Jones、M.、de Medeiros、B。、およびC. Mortimore、「OpenID Connect Core 1.0」、2014年11月、<https://openid.net/specs/openid-connect-core-1_0.html>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SessionInitiationProtocol」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティの考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https://www.rfc-editor.org/info / rfc3552>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https://www.rfc-editor.org/info/rfc3711>。
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004, <https://www.rfc-editor.org/info/rfc3760>.
[RFC3760] Gustafson、D.、Just、M。、およびM. Nystrom、「Securely Available Credentials（SACRED）-Credential Server Framework」、RFC 3760、DOI 10.17487 / RFC3760、2004年4月、<https：//www.rfc-editor.org/info/rfc3760>。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4251] Ylonen、T。およびC. Lonvick、Ed。、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<https://www.rfc-editor.org/info / rfc4251>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「Media Streamsのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、DOI 10.17487 / RFC4568、2006年7月、<https：// www。rfc-editor.org/info/rfc4568>。
[RFC5479] Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, DOI 10.17487/RFC5479, April 2009, <https://www.rfc-editor.org/info/rfc5479>.
[RFC5479] Wing、D.、Ed。、Fries、S.、Tschofenig、H.、and F. Audet、 "Requirements and Analysis of Media Security Management Protocols"、RFC 5479、DOI 10.17487 / RFC5479、April 2009、<https：//www.rfc-editor.org/info/rfc5479>。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「Datagram Transport Layer Security（DTLS）を使用してセキュアなReal-time Transport Protocol（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、DOI 10.17487 /RFC5763、2010年5月、<https://www.rfc-editor.org/info/rfc5763>。
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.
[RFC6189] Zimmermann、P.、Johnston、A.、Ed。、およびJ. Callas、「ZRTP：Unicast Secure RTPのメディアパスキー合意」、RFC 6189、DOI 10.17487 / RFC6189、2011年4月、<https：//www.rfc-editor.org/info/rfc6189>。
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011, <https://www.rfc-editor.org/info/rfc6222>.
[RFC6222] Begen、A.、Perkins、C。、およびD. Wing、「RTP制御プロトコル（RTCP）正規名（CNAME）を選択するためのガイドライン」、RFC 6222、DOI 10.17487 / RFC6222、2011年4月、<https：//www.rfc-editor.org/info/rfc6222>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<https://www.rfc-editor.org/info/rfc6454>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https://www.rfc-editor.org/info/rfc6455>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D.、Ed。、 "The OAuth 2.0 Authorization Framework"、RFC 6749、DOI 10.17487 / RFC6749、October 2012、<https://www.rfc-editor.org/info/rfc6749>。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）正規名（CNAME）を選択するためのガイドライン」、RFC 7022、DOI 10.17487 / RFC7022、2013年9月、<https://www.rfc-editor.org/info/rfc7022>。
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7033] Jones、P.、Salgueiro、G.、Jones、M。、およびJ. Smarr、「WebFinger」、RFC 7033、DOI 10.17487 / RFC7033、2013年9月、<https://www.rfc-editor.org/ info / rfc7033>。
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC7675] Perumal、M.、Wing、D.、Ravindranath、R.、Reddy、T.、and M. Thomson、 "Session Traversal Utilities for NAT（STUN）Usage for Consent Freshness"、RFC 7675、DOI 10.17487 / RFC7675、2015年10月、<https://www.rfc-editor.org/info/rfc7675>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.
[RFC8825] Alvestrand、H。、「Overview：Real-Time Protocols for Browser-Based Applications」、RFC 8825、DOI 10.17487 / RFC8825、2021年1月、<https://www.rfc-editor.org/info/rfc8825>。
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[RFC8827] Rescorla、E。、「WebRTC Security Architecture」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<https://www.rfc-editor.org/info/rfc8827>。
[RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", RFC 8828, DOI 10.17487/RFC8828, January 2021, <https://www.rfc-editor.org/info/rfc8828>.
[RFC8828] Uberti、J。およびG. Shieh、「WebRTC IPアドレス処理要件」、RFC 8828、DOI 10.17487 / RFC8828、2021年1月、<https://www.rfc-editor.org/info/rfc8828>。
[SWF] "SWF File Format Specification Version 19", April 2013, <https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-file-format-spec.pdf>.
[SWF]「SWFファイル形式仕様バージョン19」、2013年4月、<https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-file-format-spec.pdf>。
[whitten-johnny] Whitten, A. and J.D. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", Proceedings of the 8th USENIX Security Symposium, August 1999, <https://www.usenix.org/legacy/publications/library/ proceedings/sec99/whitten.html>.
[whitten-johnny] Whitten、A。およびJD Tygar、「Why Johnny Ca n't Encrypt：A Usability Evaluation of PGP 5.0」、Proceedings of the 8th USENIX Security Symposium、1999年8月、<https://www.usenix.org/legacy/publications/library/proceedings/sec99/whitten.html>。
Acknowledgements
謝辞
Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan Johnston, Hadriel Kaplan (Section 4.2.1), Matthew Kaufman, Martin Thomson, Magnus Westerlund.
Bernard Aboba、Harald Alvestrand、Dan Druta、Cullen Jennings、Alan Johnston、Hadriel Kaplan（セクション4.2.1）、Matthew Kaufman、Martin Thomson、Magnus Westerlund
Author's Address
著者の住所
Eric Rescorla Mozilla
エリックレスコーラMozilla
Email: ekr@rtfm.com