Network Working Group A. Roach Internet-Draft Mozilla Intended status: Informational March 10, 2017 Expires: September 11, 2017 Using Privacy Enhanced Real-time Conferencing (PERC) in a WebRTC Context draft-roach-perc-webrtc-00 Abstract The Privacy-Enhanced Realtime Conferencing (PERC) architecture defines a system by which multiparty conferences can be handled by a conference server that is "semi-trusted": that is, it is trusted to correctly handle media packets, but it is not trusted with the actual contents of the media streams. In order to use this architecture within WebRTC, we must describe how information is conveyed among various network functions. This document describes the information to be conveyed and how it is transferred. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Roach Expires September 11, 2017 [Page 1] Internet-Draft PERC in WebRTC March 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Key Distributor Co-Located with Browser . . . . . . . . . 3 4.1.1. Conference Establishment . . . . . . . . . . . . . . 5 4.1.2. Owner Sends Offer to Conference . . . . . . . . . . . 7 4.1.3. Conference Processes Owner Offer . . . . . . . . . . 9 4.1.4. Owner Processes Answer . . . . . . . . . . . . . . . 10 4.1.5. Owner sets up media connection . . . . . . . . . . . 11 4.1.6. Participant Joins Conference . . . . . . . . . . . . 11 4.1.7. Conference Processes Participant Offer . . . . . . . 13 4.1.8. Participant Processes Answer . . . . . . . . . . . . 14 4.1.9. Participant sets up media connection . . . . . . . . 15 4.2. Key Distributor Separate From Browser . . . . . . . . . . 16 5. New Mechanisms Required . . . . . . . . . . . . . . . . . . . 16 5.1. New Key Distributor DOM Object . . . . . . . . . . . . . 16 5.2. New "sign" Tunnel Message . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Privacy-Enhanced Realtime Conferencing (PERC) architecture [I-D.ietf-perc-private-media-framework] defines a system by which multiparty conferences can be handled by a conference server that is "semi-trusted": that is, it is trusted to correctly handle media packets, but it is not trusted with the actual contents of the media streams. In order to use this architecture within WebRTC [W3C.WD-webrtc-20170313], we must describe how information is conveyed among various network functions. This document describes the information to be conveyed and how it is transferred. Note that the current document is a fairly high-level thumbnail sketch of information flow. It will be expanded with further detail once we have consensus on the general direction for the mechanism. Roach Expires September 11, 2017 [Page 2] Internet-Draft PERC in WebRTC March 2017 2. Terminology This document also uses a number of terms defined in section 2 of [I-D.ietf-perc-private-media-framework]. Of particular note, the definitions for "Media Distributor (MD)" and "Key Distributor (KD)" are provided by that document. 3. Goals A key goal of the mechanisms described in this document is that it should work with a minimal set of changes to web browsers that already implement WebRTC. In particular: PERC requires the use of strong identity assertions in order to provide any value whatsoever. WebRTC already contains an identity mechanism [I-D.ietf-rtcweb-security-arch]; we do not seek to introduce a second one. Regarding identity, this document assumes: o From a WebRTC perspective, the remote identity presented to each conference participant will be the identity of the Key Distributor (KD). Whether this is identical to the PeerConnection identity presented by the conference owner is a matter of policy for the conference application. (Note that this is an emergent property of the system rather than a design decision, since the DTLS associations used to key the SRTP terminate at the KD in the PERC architecture.) o The KD will validate the identity of each user as they join the conference. The roster of current users must be available to at least one of the participants through a means that can be trusted as being authentically generated by the KD. We also seek to support a system that allows for the Key Distributor (KD) to be co-located with an endpoint as a primary goal, and for the KD to be located on a dedicated server as an important secondary goal. 4. Data Flows 4.1. Key Distributor Co-Located with Browser When the KD is co-located with the browser, the browser that serves the role of KD must join the conference before any other media can be exchanged. It is up to the application to determine whether this is simply the first participant to join, or a specific participant who has an administrative relationship with the conference instance. For concision, we will use the term "conference owner" to refer to the browser serving in this role, even though its assignment may be arbitrary. Roach Expires September 11, 2017 [Page 3] Internet-Draft PERC in WebRTC March 2017 We further posit that browsers that serve as KDs will have specific objects available as part of their Document Object Model (DOM). These objects will give applications the ability to instantiate and control such KDs, but without actually being able to obtain access to the keying material itself. The definition of the interface for such objects is not defined in this document more than necessary. We envision a companion document, submitted to the W3C, to describe this API in detail. The following callflows illustrate the information exchanged among these entities: Identity Service: This is the server that acts as in Identity Provider (IdP), as that term is defined in [I-D.ietf-rtcweb-security-arch]. Note that the Owner and the Participant may use different Identity Services to vouch for their identities. Owner Browser: This is the web browser execution environment for the web browser that is acting as the KD. Owner PeerConnection: This is the RTCPeerConnection object created and used by conferencing web application running in the Owner Browser. It is shown separately from the Owner Browser to clearly indicate those tasks which are performed directly by the RTCPeerConnection without the ability for the conferencing web application to intervene. KD: This is the Key Distributor function created and used by the conferencing web application running in the Owner Browser. It is shown separately from the Owner Browser to clearly indicate those tasks which are performed directly by the Key Distributor without the ability for the conferencing web application to intervene. HTTP Server: This is the HTTP server that handles the signaling for the conference. MD: This is the media distributor that handles the media the conference. Note that the interface between the HTTP Server and the MD is an implementation detail for the developer of the conference server. The messages exchanged between them are intended to illustrate the information required to be exchanged between them to have a properly functioning PERC conference. Participant Browser: This is the web browser execution environment for a web browser that is not acting as the KD. Roach Expires September 11, 2017 [Page 4] Internet-Draft PERC in WebRTC March 2017 Participant PeerConnection: This is the RTCPeerConnection object created and used by conferencing web application running in the Participant Browser. It is shown separately from the Participant Browser to clearly indicate those tasks which are performed directly by the RTCPeerConnection without the ability for the conferencing web application to intervene. The following sub sections step through an illustrative call flow that demonstrates how the information needed to create a PERC conference in a WebRTC environment is exchanged among the aforementioned functions. The call flows occur in the order shown by these sections - division into sections is done primarily to limit the number of elements in any diagram to no more than four, since the limitations of the internet-draft format makes wider diagrams impossible. 4.1.1. Conference Establishment Roach Expires September 11, 2017 [Page 5] Internet-Draft PERC in WebRTC March 2017 Owner KD HTTP Server MD Browser | | | | | | | | | | | |(1) GET /perc/room-identifier | | |-------------------------------------->| | |(2) 200 OK (with app) | | |<--------------------------------------| | |(3) new KD(); | | | |------------------>| | | |(4) kd.setIdentity(id1); | | |------------------>| | | |(5) kd.getFingerprint(); | | |------------------>| | | |(6) fingerprint | | | |<------------------| | | |(7) POST /start-conf (KD fingerprint) | | |-------------------------------------->| | | | |(8) New Conference | | | | (KD fingerprint)| | | |------------------>| | | |(9) ack | | | |<------------------| |(10) 200 (MD name and port) | | |<--------------------------------------| | |(11) kd.connect(mdName,port) | | |------------------>| | | | |(12) TLS setup | | | |-------------------------------------->| | | | | | |KD checks that MD cert matches name | | | | | | MD checks that the client fingerprint matches | | | | | | |(13) Profiles | | | |<--------------------------------------| |(14) resolve connect promise | | |<------------------| | | | | | | 1. The conference owner loads the conference application. Although not required, information sufficient to identify the conference is frequently sent as part of the URL. 2. The HTTP server returns the conferencing web application. Roach Expires September 11, 2017 [Page 6] Internet-Draft PERC in WebRTC March 2017 3. The conferencing web application instantiates a new Key Distributor (KD) object. Upon instantiation, this KD creates a new certificate. 4. The conferencing web app sets the owner's identity on the KD. 5. The application asks for the certificate's fingerprint... 6. ...which the KD provides 7. The application initiates the conference, including the KD cert fingerprint as part of the initiation message. 8. The HTTP server passes the KD fingerprint along to the Media Distributor (MD). This is used later by the MD to ensure that the correct KD is connecting to it. 9. The MD acknowledges creation of a new conference. This acknowledgement contains the hostname and port that the MD is listening on for the KD to connect to. 10. The web server responds to the conferencing web app with the hostname of the MD as well as the port it is listening on for the KD to connect. 11. The application passes along the MD name and port to the KD object. 12. The KD initiates a TLS connection to the MD. This connection uses the protocol defined in [I-D.ietf-perc-dtls-tunnel]. The KD verifies that the certificate presented by the MD matches the name it used to connect to it, and that it chains up to a trusted certificate authority. The MD verifies that the client cert provided by the KD matches the fingerprint that it received earlier from the HTTP server. 13. The MD returns its list of supported profiles, as described in [I-D.ietf-perc-dtls-tunnel]. 14. The KD object indicates to the conferencing app that the KD-MD connection has been successfully established. 4.1.2. Owner Sends Offer to Conference Roach Expires September 11, 2017 [Page 7] Internet-Draft PERC in WebRTC March 2017 Identity Owner Owner HTTP Service Browser PeerConnection Server | | | | | | | | | |(1) new PC(); | | | |------------------>| | | |(2) setIdentity(id1); | | |------------------>| | | |(3) createOffer(); | | | |------------------>| | |(4) GET /.well-known/idp-proxy/default | | |<--------------------------------------| | |(5) 200 | | | |-------------------------------------->| | |(6) XHR POST /sign (offer) | | |<--------------------------------------| | |(7) 200 (signed offer) | | |-------------------------------------->| | | |(8) resolve createOffer() promise | | |<------------------| | | |(9) POST /perc/offer?room-identifier | | |(with signed offer)| | | |-------------------------------------->| | | | | 1. The conferencing web application creates a new WebRTC RTCPeerConnection (PC) object to allow sending and receiving media. 2. The conferencing web app sets the owner's identity on the PC... 3. ...and requests an offer to be created. 4. As described in [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy code from the Identity Service... 5. ...which it returns. 6. Upon being executed, the idp-proxy code sends the offer to the Identity service... 7. ...which verifies user's identity, the signs the offer, and returns the signed offer to the PC. 8. The PC then returns the signed offer to the conferencing web app. 9. The conferencing web app sends the signed offer to the HTTP server to begin establishing the media connection. Roach Expires September 11, 2017 [Page 8] Internet-Draft PERC in WebRTC March 2017 4.1.3. Conference Processes Owner Offer Identity KD HTTP MD Service Server | | | | | | |(1) signed offer | | | |------------------>| | | | | | |(2) sign(offer, answer) | | |<--------------------------------------| |(3) GET /.well-known/idp-proxy/default | | |<------------------| | | |(4) 200 (with public key) | | |------------------>| | | |(5) GET /.well-known/idp-proxy/default | | |<------------------| | | |(6) 200 | | | |------------------>| | | |(7) XHR POST /sign (MD answer) | | |<------------------| | | |(8) 200 (signed MD answer) | | |------------------>| | | | |(9) signed answer, KD identity | | |-------------------------------------->| | | |(10) signed answer | | | |<------------------| | | | | In this section of the flow, the MD sends generates an answer. It sends this answer to the KD so that it can sign it with an assertion of the KD's identity. It also sends the corresponding offer to the KD so that the KD can validate that the authenticated party who generated the offer is authorized to join the conference, and to allow the KD to add that user to its own notion of the current conference roster. 1. The HTTP server sends the signed offer to the MD to allow it to start setting up the media connection. 2. The MD creates an answer to the received offer, and sends both offer and answer over the MD-KD tunnel connection. 3. Similar to the PC validation procedure described in [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy code from the Identity Service based on the identity in the offer... Roach Expires September 11, 2017 [Page 9] Internet-Draft PERC in WebRTC March 2017 4. ...which it returns. The KD uses the IDP proxy code to validate the identity of the party that generated the offer. 5. Similar to the PC signing procedure described in [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy code from the Identity Service... 6. ...which it returns. 7. Upon being executed, the idp-proxy code sends the MD answer to the Identity Service... 8. ...which verifies KD's identity, the signs the MD answer, and returns the signed MD answer to the KD. 9. The KD sends the signed MD answer back to the MD. 10. The MD sends the signed answer to the HTTP server. 4.1.4. Owner Processes Answer Identity Owner Owner HTTP Service Browser PeerConnection Server | | | | | | | | | | | | | |(1) 200 (signed answer) | | |<--------------------------------------| | |(2) setRemoteDescription(answer) | | |------------------>| | |(3) GET /.well-known/idp-proxy/default | | |<--------------------------------------| | |(4) 200 (with public key) | | |-------------------------------------->| | |PC validates signature with public key from Identity Service | | | | | | | | 1. To complete the offer/answer exchange, the HTTP server returns the signed answer (asserting the KD's identity) to the owner's conference web app. 2. The conference web app sets the remote description on the PC to the received answer 3. Using the identity validation procedure described in [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy Roach Expires September 11, 2017 [Page 10] Internet-Draft PERC in WebRTC March 2017 code from the Identity Service based on the identity in the answer... 4. ...which it returns. The PC uses the IDP proxy code to validate the identity of the party that generated the answer. 4.1.5. Owner sets up media connection Note: ICE/ICE Lite is not shown in this flow, but is assumed to have taken place. Owner KD MD PeerConnection | | | | | | |(1) DTLS setup | | |-------------------------------------->| | |(2) Tunnel(DTLS setup) | |<------------------| |(3) Double encrypted media | |.......................................| | | | | | | 1. The PC, using the addressing information present in the answer, negotiates a DTLS association towards the MD. We make an assumption that the SDP generated by the MD contains a port number that is unique to the conference, allowing it to correlate the incoming DTLS messages to the correct KD. 2. The MD uses the tunneling protocol defined in [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages between the PC and the KD. These DTLS setup messages make use of the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to establish end-to-end keys for the media. 3. Using the mechanism described in [I-D.ietf-perc-double], the PC now begins to send and received SRTP-encrypted media to and from the MD. 4.1.6. Participant Joins Conference After the conference has been established as described in the preceding sections, each new participant triggers a flow that closely mirrors the owner PC's interaction with the conference. These steps are shown in the following sections. Roach Expires September 11, 2017 [Page 11] Internet-Draft PERC in WebRTC March 2017 HTTP Participant Participant Identity Server Browser PeerConnection Service | | | | |(1) GET /perc/room-identifier | | |<------------------| | | |(2) 200 OK (with app) | | |------------------>| | | | |(3) new PC(); | | | |------------------>| | | |(4) setIdentity(id2); | | |------------------>| | | |(5) createOffer(); | | | |------------------>| | | | |(6) GET | | | |/.well-known/idp-proxy/default | | |------------------>| | | |(7) 200 | | | |<------------------| | | |(8) XHR POST /sign (offer) | | |------------------>| | | |(9) 200 (signed offer) | | |<------------------| | |(10) resolve createOffer() promise | | |<------------------| | |(11) POST /perc/offer?room-identifier (signed offer) | |<------------------| | | | | | | 1. The conference owner loads the conference application. Although not required, information sufficient to identify the conference is frequently sent as part of the URL. 2. The HTTP server returns the conferencing web application. 3. The conferencing web application creates a new WebRTC RTCPeerConnection (PC) object to allow sending and receiving media. 4. The conferencing web app sets the owner's identity on the PC... 5. ...and requests an offer to be created. 6. As described in [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy code from the Identity Service... 7. ...which it returns. Roach Expires September 11, 2017 [Page 12] Internet-Draft PERC in WebRTC March 2017 8. Upon being executed, the idp-proxy code sends the offer to the Identity service... 9. ...which verifies user's identity, the signs the offer, and returns the signed offer to the PC. 10. The PC then returns the signed offer to the conferencing web app. 11. The conferencing web app sends the signed offer to the HTTP server to begin establishing the media connection. 4.1.7. Conference Processes Participant Offer Identity KD HTTP MD Service Server | | | | | | |(1) offer | | | |------------------>| | |(2) sign(offer, answer) | | |<--------------------------------------| |(3) GET /.well-known/idp-proxy/default | | |<------------------| | | |(4) 200 (with public key) | | |------------------>| | | |(5) GET /.well-known/idp-proxy/default | | |<------------------| | | |(6) 200 | | | |------------------>| | | |(7) XHR POST /sign (MD answer) | | |<------------------| | | |(8) 200 (signed MD answer) | | |------------------>| | | | |(9) signed answer, KD identity | | |-------------------------------------->| | | |(10) signed answer | | | |<------------------| | | | | This flow is identical to conference processing of the owner's offer. It is included here for completeness. 1. The HTTP server sends the signed offer to the MD to allow it to start setting up the media connection. 2. The MD creates an answer to the received offer, and sends both offer and answer over the MD-KD tunnel connection. Roach Expires September 11, 2017 [Page 13] Internet-Draft PERC in WebRTC March 2017 3. Similar to the PC validation procedure described in [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy code from the Identity Service based on the identity in the offer... 4. ...which it returns. The KD uses the IDP proxy code to validate the identity of the party that generated the offer. 5. Similar to the PC signing procedure described in [I-D.ietf-rtcweb-security-arch], the KD requests the IDP proxy code from the Identity Service... 6. ...which it returns. 7. Upon being executed, the idp-proxy code sends the MD answer to the Identity Service... 8. ...which verifies KD's identity, the signs the MD answer, and returns the signed MD answer to the KD. 9. The KD sends the signed MD answer back to the MD. 10. The MD sends the signed answer to the HTTP server. 4.1.8. Participant Processes Answer Identity HTTP Participant Participant Service Server Browser PeerConnection | | | | | | | | | | | | | |(1) 200 (signed answer) | | |------------------>| | | | |(2) setRemoteDescription | | | (answer) | | | |------------------>| |(3) GET /.well-known/idp-proxy/default | | |<----------------------------------------------------------| |(4) 200 (with public key) | | |---------------------------------------------------------->| |PC validates signature with public key from Identity Service | | | | This flow is identical to owner's processing of the conference's answer. It is included here for completeness. Roach Expires September 11, 2017 [Page 14] Internet-Draft PERC in WebRTC March 2017 1. To complete the offer/answer exchange, the HTTP server returns the signed answer (asserting the KD's identity) to the owner's conference web app. 2. The conference web app sets the remote description on the PC to the received answer 3. Using the identity validation procedure described in [I-D.ietf-rtcweb-security-arch], the PC requests the IDP proxy code from the Identity Service based on the identity in the answer... 4. ...which it returns. The PC uses the IDP proxy code to validate the identity of the party that generated the answer. 4.1.9. Participant sets up media connection KD MDD Participant PeerConnection | | | | |(1) DTLS setup | | |<------------------| |(2) Tunnel(DTLS setup) | |<------------------| | | |(3) Double encrypted media | |...................| | | | This flow is identical to the owner's establishment of encrypted media. It is included here for completeness. 1. The PC, using the addressing information present in the answer, negotiates a DTLS association towards the MD. We make an assumption that the SDP generated by the MD contains a port number that is unique to the conference, allowing it to correlate the incoming DTLS messages to the correct KD. 2. The MD uses the tunneling protocol defined in [I-D.ietf-perc-dtls-tunnel] to forward the DTLS setup messages between the PC and the KD. These DTLS setup messages make use of the mechanism described in [I-D.ietf-perc-srtp-ekt-diet] to establish end-to-end keys for the media. 3. Using the mechanism described in [I-D.ietf-perc-double], the PC now begins to send and received SRTP-encrypted media to and from the MD. Roach Expires September 11, 2017 [Page 15] Internet-Draft PERC in WebRTC March 2017 4.2. Key Distributor Separate From Browser This configuration introduces a couple of challenges. It is not explored in depth in this version of the document; however, we highlight the following two issues: o Because identity in WebRTC is inherently based on evaluation of Javascript, and because the KD must validate identities to perform its intended purpose, the KD will be required to include a Javascript execution environment. o Because the KD is the only trusted node that inherently has access to the list of active conference participants, we must introduce additional mechanisms that allow it to convey this information to conference participants in a way that can be authenticated. 5. New Mechanisms Required Based on the foregoing message flows, we need to add a small number of new mechanisms to the overall system. 5.1. New Key Distributor DOM Object Although the formal definition of the Key Distributor DOM object will be provided by a W3C document, the foregoing message flows imply that we will need an interface that looks roughly like the following. This interface is expressed using the syntax defined by [W3C.CR-WebIDL-1-20160308], and refers to a number of structures defined in [W3C.WD-webrtc-20170313]. interface RTCKeyDistributor : EventTarget { void setIdentityProvider(DOMString provider, optional RTCIdentityProviderOptions options); Promise getIdentityAssertion(); readonly attribute Promise peerIdentity; readonly attribute DOMString? idpLoginUrl; readonly attribute DOMString? idpErrorInfo; Promise getCertificate(); Promise connect(DOMString mdHost, unsigned short mdPort); attribute EventHandler onfingerprintfailure; } Roach Expires September 11, 2017 [Page 16] Internet-Draft PERC in WebRTC March 2017 5.2. New "sign" Tunnel Message We also need to add new "sign_answer" and "sign_answer_ack" MsgTypes to the protocol defined in [I-D.ietf-perc-dtls-tunnel]. These are used by the MD to request that the KD sign its answer. The "SignAnswer" message is defined as follows: struct { opaque offer<1..2^24-1>; opaque answer<1..2^24-1>; } SignAnswer; The "SignAnswerAck" message is defined as follows: struct { opaque answer<1..2^24-1>; } SignAnswerAck; 6. Security Considerations This section will be fleshed out further after the working group has general agreement about the direction this mechanism should take. The means by which the KD determines that the offer being presented in the "sign" message corresponds to the current conference and has not been replayed has not yet been analyzed. We need to ensure that MD answers signed by the KD cannot be used by the MD as offers in other contexts, as doing so would allow the MD to impersonate the KD's identity. 7. IANA Considerations This document requires no actions from IANA. 8. References 8.1. Normative References [I-D.ietf-perc-double] Jennings, C., Jones, P., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-02 (work in progress), October 2016. Roach Expires September 11, 2017 [Page 17] Internet-Draft PERC in WebRTC March 2017 [I-D.ietf-perc-dtls-tunnel] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00 (work in progress), March 2017. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key Transport for Secure RTP", draft-ietf-perc- srtp-ekt-diet-02 (work in progress), October 2016. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-12 (work in progress), June 2016. [W3C.CR-WebIDL-1-20160308] McCormack, C. and B. Zbarsky, "WebIDL Level 1", World Wide Web Consortium CR CR-WebIDL-1-20160308, March 2016, . [W3C.WD-webrtc-20170313] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., and B. Aboba, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20170313, March 2017, . 8.2. Informative References [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing", draft-ietf-perc-private-media-framework-02 (work in progress), October 2016. Author's Address Adam Roach Mozilla \ Dallas US Phone: +1 650 903 0800 x863 Email: adam@nostrum.com Roach Expires September 11, 2017 [Page 18]